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From the Editor’s Desk 

Maybe it's the upcoming elections. Maybe it's 
summer. Maybe it's negative ions in the air. 
Whatever it is, people are certainly talking. 

For many years I have included a solicitation or 
exhortation at the end of many postings, articles, 
and editorials - "Write an article," "Debate this 
point," "Send in your comments and requests." 
The response would be maybe 5-10 replies or 
comments a year. Recently, however, there's been 
a tremendous increase in traffic on the net in both 
newsgroups and private mail. It's an electronic 
Renaissance! I hope that this constructive trend 
continues, with postings that are reasoned, logi¬ 
cal, and (best of all) creative. 

In this issue, I am delighted that so many mem¬ 
bers have submitted their work. Of special note is 
the first-ever report on a USENIX workshop, see 
page 4. 

You'll also see the inaugural SAGE section, SAGE, 
the System Administrators Guild, was launched 
along with other potential Special Technical 
Groups (STGs), by the Association at the San 
Antonio conference. 

As 'Conference Convener' for the Winter USENIX 
conference in San Diego, I'm hoping to identify 
note-takers and volunteers who can summarize 
sessions and BOFs. I'm looking for writers who 
who can distill high points so members who 
aren't able to attend the conference can scan the 
most important or provocative points from the 
keynote, tech sessions, invited talks, and BOFs. If 
you're interested in volunteering, please send me 
your name, e-mail address, and interests. 

Of course, we're always looking for more mate¬ 
rial for this newsletter. Please contact me at 
kolstad@bsdi.com with articles ranging from 200 
word fillers to full blown technical discussions. 

You'll note that the 'look' of this newsletter is 
evolving. USENIX's resident formatter, Carolyn 
Carr, gets the credit for these improvements. 
Watch over the next few months for greater read¬ 
ability and layout. Thanks, Carolyn! 
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Special Technical Groups and SAGE 


USENIX Launches Special Technical 
Groups & Local Technical Groups 

"USENIX is excited to have this new venue for our 
members to participate in ever-more focussed 
activities under the Association's umbrella/' said 
outgoing President Marshall Kirk McKusick as he 
announced a new policy for creation of Special 
Technical Groups (STGs) at the San Antonio Tech¬ 
nical conference. 

STGs will provide a mechanism for aU interested 
members of the Association to pursue technical 
and professional interests within a narrow focus 
while remaining within the larger framework of 
the USENIX Association. 

The first STG to be chartered is SAGE (see below). 
This group will be concerned with systems 
administration issues. 

At the same time the Association created a frame¬ 
work for the chartering of Local Technical Groups 
(LTGs). LTGs will provide a mechanism for Asso¬ 
ciation members to conduct activities on a local 
level and be formally recognized by USENIX. This 
will encourage frequent, coUegial information 
exchange. 

Further information on the process of establish¬ 
ing STGs and LTGs will appear in the forthcoming 
issue of this newsletter. 

USENIX Launches SAGE: 

Systems Administrators’ Guild 

On Jime 9, USENIX laimched SAGE, the Systems 
Administrators' Guild, as the first USENIX Special 
Technical Group. SAGE is devoted to the advance¬ 
ment of systems administration as a profession. 
USENIX and SAGE will work jointly to publish 


technical information and sponsor conferences, 
workshops, tutorials, and local groups in the sys¬ 
tems administration field. 

An interim board was appointed, including Eliz¬ 
abeth Zwicky (from SRI International) President, 
John F. Detke (from Octel) Treasurer, Tina Dar- 
mohray (from Lawrence Livermore National 
Laboratories) Secretary, and Bryan McDonald 
(from SRI International) Publications Coordina¬ 
tor. Elections will be held after the LISA Confer¬ 
ence in October to elect a new board, which will 
take office in January, 1993. 

Stephen C. Johnson, incoming USENIX President, 
said, "Our aim in laimching SAGE is to encourage 
the recognition of systems administration as an 
increasingly important technical and professional 
specialty. Because Unix systems typically have 
extensive network support, Unix systems admin¬ 
istrators are being called upon to develop and 
administer corporate networks that include PCs, 
Macintoshes, and worldwide networking. The 
critical nature of these tasks, and their technical 
complexity, makes it appropriate for USENIX to 
encourage the development, interchange, and 
publication of tools and techniques for systems 
administration." Elizabeth Zwicky, interim SAGE 
President, said, "USENIX has historically sup¬ 
ported the systems administration community 
through the armual LISA Conference. We are look¬ 
ing forward to working closely with USENIX to 
expand that support, providing more avenues for 
the professional and technical growth of the 
field." 

If you would like to join SAGE, please use the 
enclosed application form included on page 23 
of this issue. 
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Micro-Kernel Workshop Report 


Report on the Workshop on Micro- 
Kernels and Other Kernel Architectures 

Seattle, WA, April 27-28,1992 

by Peter S. Langston 

<psl@bellcore.com> 

The first USENIX Workshop on Micro-Kernels and 
Other Kernel Architectures was held on April 27- 
28 in sylvan Seattle, Washington (a.k.a. the 
'"Emerald City" for the same reason that it is a.k.a. 
the "Rain City"). With 334 attendees, more than 
three times the anticipated number, this was not 
so much a workshop as an SRO conference - liter¬ 
ally every seat in the huge meeting room was 
taken and some people even had to be turned 
away. The rest of the title of this workshop/con¬ 
ference also managed to cause controversy. While 
some thought that the title should logically have 
been reduced to "Workshop on Kernel Architec¬ 
tures," others thought that the workshop was 
probably aimed at comparing and contrasting 
existing micro-kernels and their macro-kernel 
counterparts and therefore should have been 
called "Workshop on Micro-Kernels vs. Other 
Kernel Architectures." Still others questioned the 
use of the term "micro-kernel" to describe sys¬ 
tems that require several megabytes of memory 
to operate a light switch ("Does this mean that 
MVS was really an early micro-kernel?"). In any 
case, the persistent inclusion of phrases such as 
"and other kernels" betrayed the catholic inten¬ 
tions of the organizers. 

Monday, April 27 

As advertised, the first day's sessions dealt with 
introductory talks on currently important micro¬ 
kernels "and other kernels." After the opening 
remarks from Program Chair Lori Grob, five one- 
hour overview talks were presented. 

Robbert van Renesse (Vrije Universiteit/Comell 
University) presented a "Short Overview of 
Amoeba" which was an update on a talk that has 
been given a few times before. His talk featured 
some interesting new slides including one that 
was the basis for Figure 1 shown here (with the 
addition of an NT column and minor editing by 
me). 

Rich Draves (Carnegie Mellon University) gave a 
talk on "Microkernel Operating System Architec¬ 


ture and Mach" that was characterized by one of 
the other paper presenters as "the most realistic 
Mach talk ever." That evaluation may have been 
influenced by a section of the talk dealing with 
difficult decisions and things that they might do 
differently next time. 

Dave Presotto (AT&T Bell Laboratories) des¬ 
cribed "Plan 9, A Distributed System." Aside 
from describing the ideas and implementation of 
Plan 9 (simplification and minimalism expressed 
as taking a few good ideas and using them to 
extremes), Dave also described a luxurious back¬ 
up system and provided some aphorisms: "file 
systems are cool," "name spaces are cool," and so 
on. 

Marc Rozier (Chorus Systemes) gave an "Over¬ 
view of the Chorus Distributed Operating Sys¬ 
tem" that placed it both historically and 
technically. Much of Chorus' terminology pre¬ 
dates the current crop of buzzwords, making the 
associated paper refreshingly free of them. But 
not to be left behind, Marc's talk joined the rush 
into the mid-90's with a "nano-kernel" (==_ Real¬ 
time Executive). Marc also described "COOL" 
(Chorus Object Oriented Layer) but missed the 
chance to aphorize that "Chorus's object oriented 
layers are cool." 

David Cutler (Microsoft Corporation) spoke on 
"Microsoft Windows NT" giving a broad over¬ 
view ranging from Microsoft's systems strategy 
and market perspective through architectural 
issues to time and space measurements. David 
made the observation that NT is hardly a micro¬ 
kernel and must be the "other kernel architec¬ 
ture" mentioned in the workshop title. The next 
session, chaired by Dag Johansen (University of 
Tromso), was on "New Architectures" and con¬ 
sisted of two papers. 

Jonathan Walpole (Oregon Graduate Institute of 
Science and Technology) described "Modularity 
and Interfaces in Micro-Kernel Design and Imple¬ 
mentation: A Case Study of Chorus on the HP-PA 
Rise." This port of Chorus to the HP PA-RISC 
workstation took a year to do, imcovered com¬ 
mon but inefficient operating system interface 
architectural assumptions, and illustrated the 
tradeoff between micro-kernel modularity and 
performance. Even better, the first sentence of the 
paper's abstract actually answers one of the ques- 
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tions raised by the workshop's statement of pur¬ 
pose. 

Toshio Okamoto presented a paper entitled "A 
Micro Kernel Architecture for Next Generation 
Proces sors" outlining a design for an OS kernel 
that takes advantage of the large address space of 
new processors. Three design features are postu¬ 
lated: single virtual storage (no context switch 
address remapping), one-level storage (files, 
libraries, etc. are all parts of the single address 
space), and fine-grain memory protection (PTEs 
and two kinds of ACLs implemented by a fancy 


For the panel members I have used initials (so 
only really smart people will know who said 
what). 

PH: It's all lies! It's all the same bloat as a Unix 
kernel - so why is it “micro"? 

RD: You can throw away the Unix part of the 
bloat... 

PH: But then it's not useful! 

JL: If you want to make money it will have to 
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Figure 1 


MMU). Any paper that shows the subroutine call as 
a new way to do message-passing gets my vote. 

The final session of the day was the Micro-Kernels 
Panel Session moderated [sic] by Peter Honeyman 
(University of Michigan). The panelists were: Dave 
Presotto, David Cutler, Rich Draves, Jim Lipkis 
(Chorus Systemes), and Robbert van Renesse. It is 
not unusual for the moderator of such a panel dis¬ 
cussion to have to calm down the panelists and act 
as peacemaker; that did not happen. What did hap¬ 
pen? Well, here's what I was able to write down. I 
started out indicating all the places where there was 
general laughter or applause, but there were so 
many that I had to give it up. “Floor" is used to 
indicate a question or comment from “the floor." 


have Unix. 

DC: or DOS.... [discussion of some Plan 9 port 
that was done in 7 days - mostly the time it took 
Ken Thompson to port the C compiler.] 

DC: Have you guys got any more of those porting 
guys? I'd like a couple. 

PH.: I don't think you can afford them, Dave. 

[D .P. talks a lot and teases Chorus for their di¬ 
agrams] ... 

PH: Dave, what does NT stand for, anyway? It 
certainly couldn't be “New Technology"... 

DC: If you've ever seen the inside of DOS you'd 
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see why NT is New Technology. 

PH: rd like to be the first to welcome Microsoft 
into the 1970s.... 

PH: Everyone but Plan 9 claims to be a virtual 
"porting machine." 

... [PH asks a confusing question of JL and then 
tries again and makes it coherent and gets a care¬ 
ful, coherent, and unamusing answer. This is fol¬ 
lowed by an unanswered, but much more 
amusing question.] 

...[DP berates RD for Mach trying to be all things 
for all people and wanting to make a platform 
that then requires everything else (e.g., Unix 
emulation) to be added on.] 

JL: The world outside this room doesn't care 
about minimality and cleanliness. 

DP: Now you're getting to the important point- 
none of this really matters!... [An audience mem¬ 
ber asks a question about whether any of the so- 
called micro-kernels can run in 8K of memory] 

RR: Amoeba will run on an 8k machine - with the 
right ifdefs. [JL claims that mirdmality was inves¬ 
tigated as a goal (for Chorus) and found "not to 
be a win" so all the things that were removed 
were put back in.] 

JL: Minimality itself is not much of a goal. 

Floor: [The questioner starts with a long list of the 
problems that beset developers]... So what have 
you guys done to help me with these problems? 
[A loooong silence...] 

PH: Well, I thought it was a bullshit question, too. 
... [Alittle later another audience member asks...] 

AM: Er, my question is kinda like the preceding 
one... 

PH: Well forget it! I don't want to talk about it 
anymore! 

DP: Perhaps, if you could rephrase it as a per¬ 
sonal insult?... [Mike O'Dell asks a question from 
the floor about distribution involving many 
pieces of bread, peanut butter, and a squeegee 
that no one understands but JL (maybe). So JL 
suggests a related question (that he can answer) 
and answers it. Mike seems mollified.] . 

Floor:What do these systems do when faced with 
data rates of a terabit a second? 

DP: Does "choke and die" mean anything? [gen¬ 
eral agreement] We're still limited by our inter¬ 


faces to about 10 megabytes per second. ... 

Floor: I have two questions. Blah, blah, ...[I didn't 
write down the first question]... blah? 

PH: That's a bullshit question; what's your other 
one? 

Floor: [Unfazed] Okay; Plan 9. How do you know 
what something's called if everything can have 
its own name space? 

DP: ...by convention... [he gets onto the subject of 
catching all filesystem references]... The ability to 
do that, the ability to circumcise the world,... er, 
... to circumscribe the world is immensely power¬ 
ful... 

...[there follows a fairly long discussion over 
whether Plan 9's lack of structure is a Good 
Thing. DP's apparent willingness to admit the 
possibility of being wrong creating something of 
a feeding frenzy among the other panelists.] 

PH: Well, that's it. Goodbye. 

The reception that followed was distinguished 
only by an unusual surfeit of blue sky outside the 
picture windows and an imusual deficit of beer 
from the excellent local micro-breweries. The 
appearance of six bottles of Red Hook early in the 
night (hotel leftovers) only served to whet appe¬ 
tites that could not be satisfied in the hotel. 

Tuesday, April 28 

The first session on the second day was called 
"New Systems" and was chaired by Robbert van 
Renesse. Four papers were presented. 

Charles Landau (MACS Lab, Inc.) talked about 
"The KeyKOS 9 Nanokernel Architecture." 
Development of this nanokernel system began in 
1975 and the system was in production use by 
1983. It can run in 100 kilobytes of memory and a 
subset of MVS has been ported to the KeyKOS 
platform. Designed to favor reliability and secu¬ 
rity over performance, the system requires 
extraordinary measures to set capabilities at ini¬ 
tial startup, but once set they are "persistent" and 
can be retracted only by prearrangement. This 
makes a development problem when a test sys¬ 
tem gets "weird;" even pulling the plug doesn't 
fix it because it is "persistently weird." 

Dan Hildebrand (Quantum Software Systems) 
gave "An Architectural Overview of QNX," This 
new system has only existed since 1982 and was 
(according to Intel Corp.) the first multiprocess¬ 
ing OS on the PC. The latest version is POSIX com¬ 
pliant and only requires 6.8K bytes of memory for 
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the micro-kernel, but would require nearer lOOK 
for a minimal, a.k.a. "light switch," OS, (big 
enough to be a nano-kemel, I guess). Audience 
questions concerned clock synchronization on 
the LAN and plans to port to a RISC machine 
(no). 

E. Douglas Jensen (Digital Equipment Corpora¬ 
tion) spoke on "An Architectural Overview Of 
The Alpha Real-Time Distributed Kernel." This 
amusing talk about the distributed thread, real¬ 
time, OS kernel joint project involving Concur¬ 
rent Computer Corp., DEC, and the Open Soft¬ 
ware Foimdation contained numerous pithy 
quotes - "Real Fast" is not "Real Time" - "The 
security guys are seriously anal retentive" - 
"There's nothing micro about Alpha." Strangely 
enough, in support of the last statement he men¬ 
tioned that the source code was 20,000 lines of C, 
the same number claimed for the KeyKOS nanok- 
emel. 

W.E. Kuhnhauser (German National Research 
Center for Computer Science) talked about "Per¬ 
formance of the BirliX Operating System." While 
the paper characterizes BirliX as "an operating 
system for distributed, secure, and fault-tolerant 
applications" the speaker pointed out that it may 
be viewed as a "persistent object management 
system" and not a micro-kernel in any case. On 
the other hand, this is probably the newest of the 
new systems that were presented in this session. 

During the break before the next session, the team 
that had spent the previous evening investigating 
Micro-breweries and Other Brewery Architec¬ 
tures made an appearance to give a report (the 
principal investigator's coloration could only be 
explained as a tribute to the Emerald City). Fol¬ 
lowing the break, a paper session entitled "Les¬ 
sons Learned," chaired by Edward Lazowska 
(University of Washington), presented three 
papers. 

Jun Nakajima (Fujitsu Laboratories Ltd.) 
described "Multimedia / Realtime Extensions for 
Mach 3.0" making some interesting comparisons 
between Mach 2.5 and Mach 3.0 in the process. 
He divided multimedia devices into two types - 
response-time-sensitive (event-driven) and 
response-time-insensitive (deadline-driven) and 
showed how extensions to include "realtime 
threads" and a "temporal paging system" han¬ 
dle them. 

Henry Massalin (Columbia University) spoke 
about "Reimplementing the Synthesis Kernel on 
the NeWS Workstation." Synthesis breaks most 


of the rules: it is written entirely in macro assem¬ 
bler, the kernel includes self-modifying code, it is 
blindingly fast (as are the programs that run on 
it), it is small (a minimal kernel runs in 16K RAM 
and 16K ROM), and is not called a micro-, nano-, 
pico-, or femto-kemel. Henry played a record- ing 
of some music produced by software synthesis. 
He mentioned that a keyboard note generator 
program takes 720 micro-seconds to (1) sense a 
key press, (2) create a thread, (3) attach the thread 
to the audio output, (4) start executing the thread, 
and (5) produce the beginning of the sound out¬ 
put. Henry also described some clever solutions 
to cache concurrency problems encountered by 
machines executing self-modifying code. Quincy 
and his daughter Emily appeared briefly and said 
"qua" encouragingly to the audience. 

William Davenport (Digital Equipment Corpora¬ 
tion) presented "A Model and Prototype of VMS 
Using the Mach 3.0 Kernel." Modeling VMS took 
9 months; prototyping the VMS model took 
another 3 months. A plea for a native mode Mach 
debugger was made (with agreement from the 
audience). After implementing 46 of the 250 VMS 
system services several VNS utilities were found 
to be runnable. Conclusions were drawn; micro¬ 
kernel technology is cool and multi-server tech¬ 
nology is cool, but performance is probably a 
casualty. 

Lunch was imeventful except that we got to see 
Historic Pike Place Market, ate a lot of Mexican 
food, and drank fluorescent Mexican sodas (to 
the horror of the aforementioned micro-brewery 
test team captain). 

Program chair Lori Grob was also session chair 
for the following session"Experience and Obser¬ 
vations I" comprising three papers. 

Brian Bershad (Carnegie Mellon University) 
decried "The Increasing Irrelevance of IPC Per¬ 
formance for Microkernel-Based Operating Sys¬ 
tems" while new Seattle resident Rick Rashid 
turned the slides. Four points were advanced: 
IPC has gotten faster than other stuff; caches, not 
address spaces, determine performance; all data 
does [sic] not need to go through the kernel; all 
services do not need a hardware firewall. The 
question period was initiated with the reminder 
that an imwritten rule disallows the sKde turner 
from asking questions. 

Jochen Liedtke (German National Research Cen¬ 
ter) presented a paper on "Fast Thread Manage¬ 
ment and Communication Without Continu¬ 
ations" that describes the operating system L3, 
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argues for the relevance of IPC and concludes 
that (1) IPC can be implemented really fast; (2) 
continuations will not support this job; and (3) 
availability of fast IPC changes programming 
behavior. Confused questions ensued. 

Jim Hamrick (Unisys Corporation) discussed 
''Experience with SVR4 Over Chorus" and 
stressed that the project was one of very few 
involving commercial product development with 
micro-kernels rather than academic research on 
them. Twenty-two people spent eighteen months 
bringing the project to completion. The initial 
requirements are met and the system is stable. 

The final break of the conference passed with no 
noteworthy occurrences. The chair for the last 
session "Experience and Observations 11" was 
Jim Lipkis. 

Randy Dean (Carnegie Mellon University) 
pointed out that his talk would be different from 
the paper "Data Movement in Kemelized Sys¬ 
tems" in that the paper strives to describe Chorus 
and Mach side by side while the talk just focuses 
on their similarities, which include: VM central 
caching, an external mapper, fast and reliable 
IPC, and a trap redirection mechanism. He con¬ 
cludes that kemelized systems are here [but are 
they cool?] and good file system performance is 
possi- ble. 

Marc Shapiro (INRIA) gave a design report enti¬ 
tled "Distributed Abstractions, Lightweight Ref¬ 
erences" in which a Library of useful abstractions 
structured as fragmented objects and protocols to 
support lightweight, robust, uniform, garbage 


collected, distributed references are proposed 
as amendments to current operating systems 
designs in place of the more "heavyweight" 
ports, pipes, and sockets. 

Robbert van Renesse presented "Reliable Multi¬ 
cast between Micro-Kernels," describing a re¬ 
implementation of the ISIS system designed spe¬ 
cifically to take advantage of micro-kernel tech¬ 
nology and fill in some gaps in current nucro-ker- 
nel support (e.g., cross-network communication 
and failure detection). One of the goals is to make 
the ISIS system "FTPable" and examples dealt 
with the netnews-like "ISIS news groups." 

Michael Stumm (University of Toronto) gave the 
final paper, "Designing a Scalable Operating Sys¬ 
tem for Shared Memory Multiprocessors." This 
paper proposes a structuring technique based on 
clustering to solve problems of scalability in mul¬ 
tiprocessor operating system design. 

As the second day came to a close and question¬ 
naires were handed out, attendees had a chance 
to look back over the two days and evaluate the 
workshop design. The initial overview sessions 
established a basis of reference for the later dis¬ 
cussion (and disabused the attendees of any no¬ 
tion that the term "micro-kernel" implies some- 
tlung about size). The following papers were both 
interesting and well-presented and the panel ses¬ 
sion was ... well, interestingly presented. This 
timely workshop dealt with a topic that, as the 
attendance attests, is a real "hot button," The 
organizers (and the program chair, Lori Grob, in 
particular) deserve kudos for a job well done. 


;login: July/August 1992 



Summer ‘92 Conference Report 


Best Paper Winners 

Doug Moen of Sietec Open Systems Division was 
given the Best Paper Award for A Discipline of 
Error Handling. 

Mary Baker and Mark Sullivan, UC Berkeley 
authors of The Recover Box, won the Best 
Student Paper Award. 

Both papers have been published in the USENIX 
Summer 1992 Technical Conference Proceedings. 

Works-in-Progress Report 

Organized by Lisa A. Bloch, Sun User Group and 
coordinated by Peg Schafer, BBN Systems 

A Hybrid Performance Model for NFS File 
Servers 

David N. Williams, Ericsson Network Systems, 
Richardson, TX <exudnw@exu.ericsson.$e> 

In this session we will report on a Hybrid simula¬ 
tion model of NES client-server transactions. 

Our current environment consists of over 400 
diskless SPARC workstations supported by nine 
Sune 4/490 active servers. Benchmarks combined 
with trial and error were the prime methods used 
in arriving at the current configuration. 

A number of benchmarks exist to assist in select¬ 
ing and tuning NFS servers, but benchmarking 
has its perils and limitations. Vendor-supplied 
benchmark numbers are frequently suspect, and 
not every organization has the resources or skills 
required to achieve accurate and meaningful 
results. Even after spending extensive time 
benchmarking a server, the results may not pro¬ 
vide sufficient information on how it will work in 
a specific environment. 

A discrete event simulation model of the NFS 
client-server relationship has been built which 
provides an approximate model of existing or 
proposed client-server configurations. The model 
allows for flexibility in changing parameters and 
does not require the investment in time, and pos¬ 
sibly money, that comes with benchmarking. 


Phonestation; Moving the telephone onto the 
Virtual Desktop 

Stephen Uhler, Bellcore 
<sau@bellcore.com> 

The PhoneStation system is a tool that allows a 
Sun SPARCstation to control an ordinary tele¬ 
phone line. It consists of: 1) a micro-controller 
that interfaces a telephone line with a SPARCsta¬ 
tion via a serial port and the audio connector, 2) a 
software library for the SPARCstation that pro¬ 
vides telephone interface control, digital signal 
processing (e.g., touch-tone detection), and text to 
speech conversion, and 3) a TCL based language 
for writing telephone applications. 

As an example, the system can be used to inte¬ 
grate answering machine functionality into the 
workstation environment. Voice messages appear 
as ordinary electronic mail and are played 
through the SPARCstation speaker. If mail is read 
from a dumb terminal, the PhoneStation system 
places a caU to a user specified telephone number 
and plays the voice portions of any messages. 

Texas; An efficient, highly compatible persistent ob¬ 
ject store using pointer swizzling at page fault time 

Vivek Singhal, University of Texas at Austin <sin- 
ghal@cs.utexas.edu> 

Texas is a persistent object store that implements 
huge address spaces efficiently on standard hard¬ 
ware. Pointer swizzling (address translation) at 
page fault time converts the pointers in a page 
from a long format into normal, hardware-sup¬ 
ported virtual addresses when pages are brought 
into memory. This translation is transparent to 
compiled programs, allowing the use of existing 
compilers with little or no modification. Modem 
UNIXes such as SVR4 and OSF/1 provide the 
necessary control over virtual memory with no 
modifications to the operating system. 

Gumby: The portable, high-performance file system 
that rides on the back of your Pokey file system 

Sheetal V. Kakkad, University of Texas at Austin 

Gumby is a simple log-structured file system 
built on a normal UNIX file system. The file sys¬ 
tem is built inside a single UNIX file, requiring no 
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dependencies on underlying disk geometry so it 
is quite portable. Log structure avoids the use of 
a single '"home" disk block for a logical file block, 
allowing any block to be written anywhere. This 
optimizes the file system for use with large RAM 
caches, which tend to absorb most reads and 
increase the proportion of writes. We intend to 
experiment with reordering read-only pages as 
well, to dynamically increase locality and reduce 
seeks caused by read misses. 

Knowledge-Based Systems Construction in C++ 

Vladimir Bacvanski, Aachen University of Tech¬ 
nology, Germany 

<vladimir@nuthi3Anformatik.rxvth-aachen.de> 

The examination of an applicability of appealing 
techniques from object-oriented software engi¬ 
neering to knowledge-based systems domain is 
discussed, focusing on the promising role of C-I-+ 
in this context. The entrance of expert systems 
into real industrial application arena has uncov¬ 
ered weak points of the current knowledge-based 
systems technology, especially the incomprehen¬ 
sibility, poor performance, and inability to inte¬ 
grate with non-knowledge-based systems. 

The use of C++ for building technical expert sys¬ 
tems should provide one possible framework for 
overcoming the current deficiencies. The code of 
a knowledge representation language is trans¬ 
lated into C++, bringing the possibility to use 
knowledge-based techniques while remaining in 
the well known environment, so that developers 
do not have to abandon all their skills and move 
to expensive and incompatible specialized artifi¬ 
cial intelligence workstations. Moreover, the 
combination of multiple paradigms (object-ori¬ 
ented, procedural, and the rule-based one) in the 
C++ framework produces a synergetic result. 

A new multi-paradigm system architecture is 
examined together with mechanisms which 
diminish the impedance mismatch between 
object-oriented knowledge and non-knowledge- 
based systems, providing interchangeability of 
objects which follow different paradigms. The 
object-oriented paradigm is used not only to 
model the applications, but the system's internal 
components as well. The correspondence 
between different constructs from the object-ori¬ 
ented and knowledge-based systems will be 
investigated, showing that it is possible and prof¬ 
itable to model knowledge-based systems with a 
set of C++ classes. 


Development of an event based debugger with source 
level capabilities 

J. G. Posthuma, J. Scholten, J. G. Wijnstra; 

U. Twente, Netherlands 
<posthuma@cs.utwente.nl> 

Finding a bug in an application is time consum¬ 
ing and expensive. For parallel applications, 
debugging is even harder. The behavior of paral¬ 
lel applications can only be understood by look¬ 
ing at them with great abstraction. Only specified 
events of the system should be presented to the 
user. But such events only give a hint where a bug 
could be. After this hint, the user has to look with 
greater detail. He should be able to specify both 
events of higher abstraction (for example com¬ 
munication) and source level debug events. 

Events are the basis of the debugger. An event is 
generated each time an important point is 
reached in the execution. These points can be 
specified by the programmer. An event will often 
be used to indicate a place where interaction 
between two processes takes place, since interac¬ 
tion is an important aspect of parallel applica¬ 
tions. The events of all processes are merged into 
one event stream. This stream can be used 
directly or stored in a database for later use. For a 
long running or multi-process application, the 
event stream can be quite voluminous. That is 
why a number of tools are provided to make the 
event stream data more manageable. The pro¬ 
grammer has the possibility of reducing the com¬ 
plexity by specifying filters, which remove those 
events in which the user is not interested. 

Another important tool is the behavior recog¬ 
nizer. A recognizer matches behavior as specified 
by the user in terms of events against the event 
stream generated by the application. It is not only 
possible to specify the expected behavior, but also 
the behavior that is not allowed. Recognizers can 
be used in a number of ways. First of all they can 
be used to trace down the places where the spec¬ 
ified behavior is violated. Secondly, recognizers 
are useful to summarize the behavior by replac¬ 
ing a number of events from the stream with one 
new high level event. This allows the program¬ 
mer to analyze the system at different levels of 
abstraction. A third possibility is to use recogniz¬ 
ers to specify interesting points in execution 
where some action must be performed, like a 
request for process status. This last option is only 
possible for run time debugging. The recognizers 
are also useful for analyzing events in the data¬ 
base. 
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The debugger is a mixture of an event based 
debugger, source level debugge, and a behavior 
recognition system. The event based part of the 
debugger concentrates on distributed aspects of 
the application and can be used during or after 
execution. It is not always possible to debug an 
application when using the event based ap¬ 
proach, That is why the normal source level 
debugger will be integrated in the design. In the 
future, other features may be added, in order to 
make it a complete debugger for distributed 
applications. 

MACH on a Physically Secure Crypto Coprocessor 

Elaine Pahner, IBM Research Division, Yorktown 
Heights, New York 
<epalmer@'watson.ibm.com> 

I wiU present an overview of a secure crypto¬ 
graphic workstation coprocessor. The prototype 
hardware, named 'CitadeT, was completed in 
1991 at IBM's T.J. Watson Research Center. It can 
perform DES encryption and decr)q?tion of data 
at high speeds. 

We envision its use in three possible application 
environments: 

1. It can be embedded in a communications con¬ 
troller (wire or fiber) to encrypt or decrypt some 
or aU network traffic. 

2. It can be embedded in a disk controller to 
encrypt or decrypt selected files or an entire disk. 

3. It can be installed as a secure, general purpose 
crypto coprocessor on a microchannel bus. In this 
environment it can be used to encr 3 ^t or decr 3 ^t 
passwords, authenticate users and requests for 
resources, enciypt or decrypt transactions, or 
process sensitive data from the main host proces¬ 
sor. 

In all three applications, encryption and decryp¬ 
tion does not degrade the throughput of its host 
device. The host for our prototype is an IBM 
PS/2. 

The hardware and kernel software are designed 
to operate in a physically secure package. If the 
package detects tampering, it responds by eras¬ 
ing its encryption keys and other secure memory. 
The system software is a small, multitasking 
microkernel, Mach 3.0, from Carnegie Mellon 
University. I will discuss the advantages and the 
disadvantages we've encountered in using Mach 
for this project. 


BOF Report 

by Rich Salz 

Open Software Foundation 
<rsalz@osf.org> 

A good BOF can be one of the best things to do at 
a USENIX Conference - it can keep you going aU 
night. 

BOF stands for Birds of a Feather, as in "flock 
together." It's an informal gathering of people 
who are interested in a particular area. Many 
BOFs are scheduled before the conference and 
annoimced in the conference schedule. Others are 
"scheduled" on site, and announced by posting a 
notice on the general message board. BOFs are 
not part of the standard conference track. They 
are generally held after-hours and anyone can 
attend. Many of them "adjourn to the bar," where 
the discussions can go on for hours. 

This Summer Conference's BOF topics included: 
a discussion of Standards (POSIX et al). Distrib¬ 
uted Systems Administration, Gays in comput¬ 
ing, EFF, FSF, Usenet, NNTP, UUNET, Ultrbc, Alpha, 
BSD4.4, ESDI, and Obfuscated C. I think one of the 
best things to do is to go to an area that's new to 
you. It's a great way to get practical knowledge in 
an informal setting, and a good way to meet 
experts in the field. 

Unfortunately, I didn't do that this year: I went to 
the Usenet-related BOFs because I "had to," and 
others because I wanted to get a status report. So, 
while there were no doubt lots of good things 
happening at FSF, EFF, Distributed Systems, and 
so on, I can't tell you about them. 

Tuesday; News Software & USENET 

This BOF was run by Henry Spencer and Geoff 
CoUyer. It started with an update on C News. The 
Performance Release (including much work done 
by Geoff for UUNET) is out, and the Clean-Up 
Release won't be out for "quite a while." This 
next release will have a revised soiuce tree, and 
(to the cheers of the crowd) most of the build 
work will be done directly in the Makefiles.- 

News volume is still doubling yearly, and the 
growth in newsgroups is (apparently) causing 
problems for some newsreaders, most noticeably 
when sorting the active file or deleting a news- 
group. Newsreader writers, beware: the net is 
growing faster than you think! 

The volume and newsreaders then led into a dis¬ 
cussion of threads programs like trn. Geoff is 
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thinking about looking into the issue of threads 
databases, saying ''mthreads must go/' On the 
other hand, we did get to hear the only nice thing 
Geoff has ever said about NFS: "for reading news, 
NFS is pretty good." There was also talk about 
changing the news filesystem format, to which 
Geoff replied "fix namei” 

Bruce Jones, from the School of Commimications 
at UCSD, is doing his doctorate on the growth of 
Usenet. He has Henry's old tapes from the start of 
Usenet and is trying to gauge the interest in get¬ 
ting a CD-ROM of, say, the first A News "Car for 
Sale" ad. If you're interested, send email to 
<bjones@ucsd.edu>. 

Stan Barber spoke about the next release of NNTR 
The client and server code has been split into 
pieces and the client code is in beta-test. It's 
already been ported to some PCs. The new server 
should go into alpha-test in July. If you have some 
new feature or bug fixes, let Stan know. In partic¬ 
ular, if you can help make it work well with C 
News he'd Like to hear from you. Stan can be 
reached as <nntp@tmc.edu>. 

Wednesday Night BOFs 

On Wednesday I attended the standard Usenet 
and hackers BOF track: UUNET, Obfuscated C, 
ESDI, and 4.4BSD. Even though each was only an 
hour long, this was a long night. 

Unfortunately, I missed most of the UUNET BOR I 
wandered in during a discussion of Alternet 
(UUNET's commercial IP network, no traffic 
restrictions). People are interested in low-cost 
methods like dial-up IP service. Rick Adams 
mentioned a bit about how the FBI is a customer. 
People concerned about the FBI reading netnews 
should make a reality check: the FBI wants to 
catch serial killers, they couldn't care less about 
obnoxious netnews postings! 

UUNET has also written another version of UUCP. 
ESDI has licensed it, and all UUNET customers 
will probably be able to get it, too. The most inter¬ 
esting thing about the UUNET UUCP is that you 
can replace the front-end configuration files so 
that it looks like whatever version of UUCP you 
want it to. Only BSD is supported, but HDB is an 
obvious next choice. 

Every year Landon Noll asks the people of 
Usenet to send him the most twisted C code they 
can write, and in the spring and summer he and 
his group evaluate the results and pick the best 
(or is it the worst?) they can find. No program 
could be more than 1,536 bytes of non-white- 
space, and no "cc" line could be more than 256 
bytes. Lots of whitespace was allowed this year. 


which made most of the programs a little less fun 
to look at. For the first time, there were more non- 
US winners that those from the United States. 
Every year, this is one of the best BOFs: it's very 
technical, in a weird sort of way, and it's very 
funny. 

I also detected a decided "tools" bent to this 
year's winners. It would have made a nice con¬ 
trast to the FSF EOF. While GNU software does lots 
of nice things, nobody will ever say it's small. At 
the Obfuscated C BOF, however, we got to see a 
chess program (written by Vem Paxson, the 
author of flex) that reportedly held its own against 
GNU Chess. There was also a make-like program 
that had some novel features. Both of these list¬ 
ings could fit on a single page! 

The fuil results wiQ be posted to the net (in com- 
p.lang.c, misc.misc, and other places) in a month 
or two, Landon also warned people that he and 
Larry Wall are working on an obfuscated Perl 
contest, which many in the crowd thought was 
kind of redundant. 

Berkeley Systems Design, Inc., (ESDI) is a new 
start-up that is selling BSD operating systems for 
the 386-family of machines. It's a small company, 
still struggling to meet their weekly payroll. For 
about a thousand dollars, you get the full source 
code to BSD, X, NFS, and other tools - and binaries 
to run it on your IBM PC or clone. This was the 
most overtly commercial BOF I attended: Rob 
Kolstad is an entertaining speaker, but it was 
clearly a vendor presentation. It gave information 
people clearly wanted to hear, however: the room 
was packed. The part I foimd most interesting 
was that USL (the branch of AT&T in charge of 
Unix) is suing ESDI. While you can never be sure 
when lawyers are involved, it would seem that 
they are takmg exception to the claim that the 
Berkeley "Net H" release, upon which ESDI's 
product is based, is unencumbered. I'm guessing 
that ESDI was picked because they are the first 
commercial venture that hasn't bought some sort 
of license from AT&T. For more information on 
ESDI, contact <info@bsdi.com>. 

The last BOF of the evening was the 4.4BSD EOF, 
led by Kirk McKusick and Keith Bostic of Com¬ 
puter Systems Research Group. The schedule 
said that this would include a report on the 
release schedule for 4.4BSD. This was very 
imusual as the CSRG folks from Berkeley have 
never previously announced their release sched¬ 
ule. Anyhow, 4.4 will be available in two formats: 
4.4 and 4.4 "light." The former will require an 
AT&T license; the latter wiQ contain only the 
freely-redistributable source code. This will be 
more complete than earlier free releases, but will 
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still need some work on the kernel. Both the alpha 
and the final release will be available in both for¬ 
mats, 

4.4 will have lots of filesystem features: 64 bit file- 
sizes (using the longlong datatype), NFS "'leases" 
that make NFS more efficient and robust, stack- 
able filesystems (similar to what David Rosenthal 
discussed at Baltimore; the BSD work comes from 
UCLA and the Ficus project), Idev/fd, the log- 
based filesystem (from Sprite), and so on. It will 
also make uid and gid be 32 bits, further changing 
the stat structure. These changes will all be in the 
alpha release because they involve changes in the 
system interface. The final release will have new 
TCP/IP work from Van Jacobson, the Berkeley 
streams package, and probably a new virtual 
memory system (from Mach). It will also contain 
as many documentation updates and bug fixes as 
possible. Sun has donated their shared library 
architecture, and that may also be a part of 4.4.1 
can't read my notes at this point, but I think the 
supported architectures include the Sparc, 
HP9000, Tahoe, and others. 

The bad news is that once 4.4 is solidly out the 
door, the CSRG Group is shutting down. They 
explained that it is hard to get more fimding, the 
University is using BSD less, it is too big for the 
current group to develop, and that the past year 
has not been fun: too much politics and name¬ 
calling. It's probably safe to say that the worksta¬ 
tion industry would not have happened without 
BSD, and that many of us would be doomed to be 
filling out RPGII forms in dimly-lit cubicles. 
Thanks, guys! 

Thursday BOFs 

Thursday night is always a questionable night for 
BOFs because things are always scattershot after 
the USENIX reception. This didn't stop me from 


scheduling the third Usenet-type BOF of the con¬ 
ference, however. This one concentrated on 
NNTP. The NNTP protocol is being revised by an 
Internet Engineering Task Force committee. Most 
of the revisions are related to supporting batching 
and other facilities for low-speed links. The cur¬ 
rent draft is available for FTP from turbo.bio.net 
in ~ftp/ietf-nntp. The group is not concentrating 
on facilities for news-readers. There is an unoffi¬ 
cial group working on that; send mail to 
<David_ascher@broivn.edu> if you are interested in 
that area. 

Stan Barber gave another preview of upcoming 
NNTP releases and asked for some feedback on 
specific changes to the client-side inews that is 
part of NNTP. This led to some discussion about 
news headers. There were lots of questions for me 
about INN, my Usenet/NNTP implementation. I 
mentioned it at last year's BOF and presented a 
paper on it this year so people were fairly curious. 
By the time you read this, the software should be 
available, however, so I won't take up any more 
space on self-aggrandizement. 

One last-minute BOF that was held on Thursday 
was for archive maintainers. This group is start¬ 
ing a very exciting project to make a universal 
card-catalog for software available on the net. 
Many of the people involved — Rich Morin, Ed 
Vilmietti - have lots of experience with public 
archives, and it soimds like they have a good plan 
of attack. For more information, contact cfcllrich. 

Well, that's it. I hope you thought this useful, and 
that it spurred your interest to become a full- 
fledged USENIX BOFfer. 
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Board Meeting Summary 


by Ellie Young 

Executive Director 

Below is a summary of the actions taken at the 
regular quarterly meeting of the USENIX Board of 
Directors held in San Antonio, Texas, on Jime 7, 
1992. 

Attendance 

Rick Adams, Ed Gould, Rob Kolstad, Kirk McKu- 
sick, Sharon Murrel, Evi Nemeth, Michael D. 
O'Dell, Barry Shein, Ellie Young, Judy DesHar- 
nais, Dan Klein, Eric AUman, Tom Christiansen, 
Peter Collinson, Diane DeMartini, Lori Grob, 
Steve Johnson, Greg Rose, Elizabeth Zwicky 

Summer ‘92 Conference 

Adams reported that everything seemed to be on 
track. DesHamais said that attendance from Cal¬ 
ifornia was below normal, and total attendance 
would be 1,050. Klein noted that for this confer¬ 
ence, the ratio between the number of tutorial 
seats sold to overall conference attendance is 
higher than in the past. It was suggested that he 
look into the feasibility of adding continuing edu¬ 
cation credit for tutorials. 

Microkernel Workshop 

Grob would submit a proposal for another event 
in the future, with half-day tutorials on different 
systems, with consideration that it be located next 
to SEDMS next Fall. 

File Systems Workshop 

Nemeth reported that the technical quality was 
good, the sessions were weU-attended, Peter 
Honeyman did an excellent job, and the Ann 
Arbor site was good but difficult to get to. There 
was discussion that this event should have been 
called a a symposium. It was decided that in the 
future that a limited-attendance event (e.g., 
requiring position papers) be called a workshop. 

Chair for Winter ‘94 Conference 

Yormg said she had received two proposals (one 
from Jeff Mogul and another from Clement Cole). 
It was suggested that Cole's proposal might be 
better as a workshop because of its timeliness, 
and Young was asked to discuss this possibility 
with him. It was decided to accept Mogul's pro¬ 
posal to chair this conference. 


BOFs Screening 

It was decided that screening BOFs for technical 
content was no longer necessary. 

Book Program 

O'DeU and Young reported that Jim Waldo had 
agreed to serve as editor for the USENIX papers 
on C++, and Simon Kenyon would serve as editor 
of a series on kernel technology. There were sev¬ 
eral other projects in the works, and they hoped 
to have at least four titles to laimch this series next 
year, with MIT Press as the publisher. 

IR Report. 

Collinson announced that he would be stepping 
down as the USENIX Institutional Representative 
after the October '93 POSIX meeting, and offered 
to assist in the hiring of a replacement. CoUinson 
would publish a request for proposals and field 
questions concerning the position in the coming 
months. A committee of AUman, McKusick, and 
CoUinson would review the proposals and make 
a recommendation to the Board at the next meet- 
ing. 

Policies 

It was decided to add another section to the cur¬ 
rent attendee Ust that is sorted by zip code so that 
people can locate others who are geographicaUy 
close. It was decided to postpone making a deci¬ 
sion on having the Ust avaUable online until the 
data from the attendee survey was avaUable. 
Murrel's proposed document (replacing Sections 
6.2 and 6.3 of the current policies document) 
which would divide the Association's accounts 
into two funds, thereby making them easier to 
manage, was accepted. 

Honorary Membership 

It was agreed to make Lew Law our second hon¬ 
orary Ufetime member. 

STGs/SAGE 

It was decided to adopt Adams' SIG proposal doc¬ 
ument with three amendments. The first amend¬ 
ment clarifies that 1) USENIX has complete 
responsibUity for the LISA conferences, 2) that all 
members of the SIGs must be members of USENIX, 
and 3) that the name SIG is changed to STG (Spe¬ 
cial Technical Group). 
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It was agreed to adopt Johnson's amended reso¬ 
lution creating SAGE as an STG, as follows: 

1. That the USENIX Association launch a special 
technical group to be known as USENIX/SAGE 
(Systems Administrators' Guild). This organiza¬ 
tion will engage in education, develop standards 
of excellence, recognize those who attain such 
standards, and promote work and propagate 
knowledge that advances the systems adminis¬ 
tration profession. 

2. That the USENIX Association further appoint an 
interim governing board for USENIX/SAGE, con¬ 
sisting of: 

Shoshana Abrass, 

Tina Darmohray, Secretary 

Arnold deLeon 

John F. Detke, Treasurer 

Paul Evans 

Laura deLeon 

Bryan McDonald, Publisher 

Paul M. Moriarty 

Arch Mott 

Bjorn Satdeva 

Steve Simmons 

Pat Wilson 

Elizabeth Zwicky, President 

3. That the USENIX Association immediately 
accept membership applications to be a member 
of SAGE, The pro-rated dues for the remainder of 
1992 will be $25. All SAGE members wiU also have 
to be USENIX members. 

4. That the USENIX Association will administer an 
election for a 9-member SAGE board, said election 
being concluded so that the new board can take 
office after the 1992 LISA conference. 

5. That the 1992 LISA conference base price will 
reflect the cost for SAGE members. USENIX mem¬ 
bers who are not SAGE members may check a box 
which adds $25 to the cost and makes them SAGE 
members. People who are neither USENIX or 
SAGE members check a box which makes them 
members of both organizations. 

6. That the Executive Director establish a mem¬ 
bership category for SAGE membership, and 
maintain office services (such as mailing lists and 
financial accounting) for SAGE as weU as USENIX. 
Moreover, the Executive Director will ensure that 
SAGE and the SAGE board members are covered 
by habflity insurance. 

7. That the USENIX board will appoint a formal 
liaison to the SAGE board, expecting that the 


SAGE board will likewise appoint a USENIX board 
liaison. 

8. For the 1994 LISA conference, the program chair 
for LISA will be picked by a four person commit¬ 
tee, two members of which will be appointed by 
the SAGE board and two members by the USENIX 
board. This committee will also work with the 
USENIX Tutorial Administrator to ensure rele¬ 
vant, high quality tutorials at LISA. 

9. That a regular section of ;login: will be devoted 
to material collected and submitted by SAGE. For 
the remainder of 1992, USENIX will fimd up to 
eight additional pages of material per issue, 
assuming that the material is forthcoming. Fur¬ 
thermore, should the amoimt of material grow 
considerably, USENIX will plan to establish a 
SAGE newsletter in the future. 

10. That the USENIX Association recognizes that 
financial issues have the potential to become a 
major block to easy cooperation with SAGE, and 
that the key to avoiding these problems is open¬ 
ness in our financial dealings and mutual striving 
for a fair allocation of resources. For the remain¬ 
der of 1992, USENIX will pay for the SAGE elec¬ 
tion, board expenses, legal and liability expenses 
(if any), the cost of administering SAGE member¬ 
ship, and additional )login: pages. In turn, USENIX 
will collect the SAGE interim dues. The SAGE 
board will submit a proposed budget for the fiscal 
1993 year to the USENIX Board at their fall meet¬ 
ing, including a proposal for 1993 SAGE dues and 
membership estimates. The final budget will be 
established by the USENIX board in consultation 
with those members of the SAGE board so desig¬ 
nated. We expect at that time that designated 
members of the SAGE board will have signature 
authority over the budgeted amounts. 

11. That a committee be struck consisting of the 
Presidents and Treasurers of both USENIX and 
SAGE and the USENIX Executive Director to refine 
the SAGE Bylaws and the USENIX Special Techni¬ 
cal Group Policy to bring them into agreement. 

12. The USENIX Board will conduct a progress 
review in September of 1993. 

Kolstad was delegated to be the USENIX represen¬ 
tative at the first SAGE meeting, and Christiansen 
would be the longer term representative. 

It was also agreed to allocate $6,000 in the budget 
for the SAGE STG for fiscal year 1992. 
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SAGE Mission Statement and Charter 


The Systems Administrators' Guild (SAGE) was 
founded with the following proposed charter, 
drafted by the original SAGE committee during 
the months prior to the public announcement by 
USENIX. This charter will be reviewed and modi¬ 
fied by the incoming board as they deem it neces¬ 
sary 

The purpose of the Systems Administrators' 
Guild (SAGE) will be to advance the status of sys¬ 
tems administration as a profession. SAGE will do 
so by recruiting talented individuals to the pro¬ 
fession, by developing guidelines for the educa¬ 
tion of members of the profession, by establishing 
standards of professional excellence and provid¬ 
ing recognition for those who attain them, and by 
promoting work that advances the state of the art 
and propagates knowledge of good practice in 
the profession, 

SAGE will seek to meet these objectives by offer¬ 
ing its members the following services: 

1. Conferences 

SAGE will sponsor technical conferences and 
workshops. 

2. Publications and Distributions 

SAGE will publish a technical journal and a news¬ 
letter. It will also make existing freely distribut¬ 
able systems administration tools available to its 
members, and commission the development of 
new tools. 


3. Education 

SAGE will develop curriculum recommendations 
for educational programs in systems administra¬ 
tion. It will also develop recommendations and 
accreditation for internship/residency training 
programs for systems administrators, 

4. Certification 

SAGE will develop a process for the certification 
of professional systems administrators by exami¬ 
nation, and will maintain a registry of certified 
professional systems administrators. 

5. Job Descriptions 

SAGE will develop model job descriptions for var¬ 
ious classes of professional systems administra¬ 
tors. 

6. Awards 

SAGE wiU recognize outstanding achievement in 
professional systems administration through 
awards like the ACM Turing and Grace Murray 
Hopper Awards. 

7. Public Relations 

SAGE will speak for the concerns of its members 
to the media. It will make public statements on 
issues related to systems administration. 

6. Local Groups 

SAGE will promote the creation of local groups of 
professional systems administrators, like Bay- 
LISA. 
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SAGE Governing Board and Elections 


In order to ensure a smooth transition from the 
design committee to the first elected governing 
board, USENIX has approved the appointments of 
the members of the committee as the interim gov¬ 
erning board of SAGE. The members of this board 
are: 

Shoshana Abrass, Pacific Data Imaging 
Tina Darmohray, Lawrence Livermore National 
Labs, Secretary 
Arnold de Leon, Synopsys 
Laura de Leon, Hewlett Packard 
John R Detke, Octet, Treasurer 
Paul Evans, Maspar 

Bryan McDonald, SRI International, Publications 
Coordinator 

Paul M. Moriarty, Cisco Systems 

Arch Mott, Protocol Engines 

Bjorn Satdeva, /sysladmin 

Steve Simmons, Inland Sea 

Pat Wilson, Dartmouth College 

Elizabeth Zwicky, SRI International, President 

This board will serve until the first fully elected 
board takes office in January, 1993, with their first 
meeting being held at the Winter USENIX confer¬ 
ence in San Diego, California. Current estimates 
indicate that the new board wiU have 4 meetings 
a year, three at LISA and USENIX technical confer¬ 
ences, and a spring meeting. At this time the 
board members are responsible for travel and 
lodging expenses for the meeting. This board will 
be tasked with further defining the charter and 


mission statements of the guild, setting the 1994 
budget, and monitoring, coordinating, and 
approving all the working groups efforts. Mem¬ 
bers of the board should expect to be spending 
significant time every week in the pursuit of these 
goals during the first year serving the board, after 
which time requirements should begin to ease a 
little. Since the board wlQ be geographically 
diverse and working on so many issues, elec¬ 
tronic mail will probably serve as a major conduit 
of information. This is a major time and financial 
commitment for at least the first year. 

SAGE is accepting nominations for new members 
of the governing board imtil October 22 at noon, 
PST. Anyone interested in running for the SAGE 
board should send their name and telephone 
number and a brief statement to the nominating 
committee at the following email address: 
<sage-nominations@usenix.org>. You can also send 
U.S. Mail to the SAGE Nominating Committee 
care of the USENIX Association. The nominating 
committee will gather the candidates' names and 
contact each of them before the election takes 
place. 

At the USENIX LISA conference in October there 
wiU be a candidates' forum to enable prospective 
board members to introduce themselves and talk 
about the issues. Prospective board members 
unable to make it to the LISA conference will be 
able to submit a position paper to this forum. 
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Report on First SAGE Meeting 


by Paul Evans 

MasPar Computer Corporation 

SAGE held an organizational meeting at the Mar- 
riot Rivercenter Hotel in San Antonio, Texas on 
June 13,1992. The meeting followed the USENIX 
summer technical conference, at which USENIX 
launched SAGE as its first Special Technical 
Group (STG). Forty-three participants attended 
the meeting. Rob Kolstad represented the 
USENIX board of directors for this meeting; other 
past and cmrent USENIX board members were 
also present: Evi Nemeth, Tom Christian-sen, Eric 
Allman, and Ed Gould. Tom Christiansen will be 
the long-term USENIX Board liaison to SAGE 
after this event. 

Steve Simmons started the meeting and intro¬ 
duced Bjorn Satdeva, who briefly discussed the 
origins of SAGE, and the name - the 'e' that was 
left off the creat(2) system call has reappeared as 
the 'e' at the end of SAGE. Rob Kolstad discussed 
the relationship between SAGE and USENIX, 
emphasizing the enthusiastic support of the 
USENIX board for the Special Technical Groups 
(STGs) in general and SAGE in particular. The 
members of the interim SAGE governing board 
who were present were introduced: Shoshana 
Abrass, John Detke, Paul Evans, Paul Moriarty, 
Bjorn Satdeva, Steve Simmons, Pat Wilson, and 
Elizabeth Zwicky. Paul Evans read the proposed 
SAGE charter. 

After the reading of the charter, there was brief 
discussion of awards which resulted in an infor¬ 
mal decision to give "'Robbies" to outstanding 
systems administrators, in honor of Rob Kolstad, 
Tlie awards working group is currently looking 
into securing a supply of chubby statuettes with 
tutus. On a more serious note. Peg Schafer of BBN 
raised the concern that the proposed charter did 
not sufficiently take the needs of part-time sys¬ 
tems administrators into accoimt. It was decided 
to create a working group to look at issues affect¬ 
ing part-time administrators, and Peg volun¬ 
teered to be its coordinator. 

Dave Coleman of IBM asked who the intended 
audience for SAGE was. He felt that since PC, 
Mac, and bulletin board administrators outnum¬ 
bered UNIX and workstation administrators by 
an order of magnitude, they might overwhelm 
SAGE. No consensus emerged on how serious 
this problem was hkely to be, so the issue was 


deferred to the working group concerned with 
admiiustrators of non-UNIX systems. Dave sug¬ 
gested that the committee should consider not 
only what to do about this issue, but also whether 
or not to do anything at aU. 

Although the original intention had been to cover 
organizational issues quickly and move on to the 
formation of the working groups, the remainder 
of the meeting was dominated by discussion 
about the structure of the SAGE board. Steve Sim¬ 
mons presented the initial proposal for a nine- 
member board, which included a president-elect, 
president and past president, each serving two- 
year terms; and six directors, each serving three- 
year terms. 

Steve proposed adopting an Australian balloting 
scheme under which candidates are ranked by 
preference. This would allow SAGE to avoid 
what is perceived as a major problem with 
USENIX elections, that unsuccessful candidates 
for the officer positions faU off the board alto¬ 
gether. However, most of the participants 
believed that this would be too complicated and 
confusing for voters. 

Pat Parseghian of AT&T was concerned that pay¬ 
ing travel costs for a nine-member board would 
be prohibitively expensive, but it was pointed out 
that SAGE has a volimteer board, and board 
members wiU be paying their own travel 
expenses. She was also concerned that there 
wasn't enough to do to justify a nine person 
board, especially considering that USENIX only 
has eight on its board. 

Many of those present expressed concern about 
the proposed presidential succession scheme, 
imder which one person would in turn serve two 
years as president-elect, president, and past pres¬ 
ident, for a total of six years. Several alternative 
arrangements were proposed, and after much 
discussion, Steve conducted a series of straw 
polls, with the following results: 

1. The SAGE board will have seven members. 

2. The SAGE board will choose its own officers 
from among the board members after 

each election (elections take place every 
year). 

3. Board members will serve two year terms. 

4. Board members are limited to foiir consecutive 
terms. 
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5. In the first election, three board members 
will be chosen for two-year terms and 
three for one-year terms. In deference to the 
strong desire of the USENIX board for continu¬ 
ity it was agreed that Ehzabeth Zwicky the 
interim president, would automatically get the 
remaining one-year term on the first elected 
board. In subsequent elections, alternately 
three and four members will be chosen for 
two-year terms. 

6. The SAGE board will determine the number 
and duties of its officers, within the limits of the 
USENIX guidelines for STGs. 

7. The first election will be held after the LISA VI 
conference in October, on a schedule to be 
determined by the USENIX Association staff. 

8. Nominations for the SAGE board will close at 
12:00 Noon (PDT) on Thursday, October 22, to 
enable the candidates to present themselves 

at a candidates' forum at the LISA conference. 
Candidates who are not able to attend the 


LISA conference can submit position papers to be 
read at the forum. 

With the conclusion of the organizational discus¬ 
sion, attention turned to the formation of the 
working groups. Some coordinators had already 
been designated for the working groups corre¬ 
sponding to the eight original charter items (con¬ 
ferences and workshops, publications, education, 
certification, job descriptions, awards, public 
relations and local groups). However, during the 
week in San Antonio, other issues emerged. Steve 
accepted volunteers to coordinate the working 
groups corresponding to these new issues (ethics, 
policies, vendors, standards, non-UNIX and part- 
time administrators). The names and email 
addresses of the coordinators were displayed, 
and names for the mailing lists were chosen. [See 
below for the complete list of working groups, 
coordinators, and maihng lists.] With this, the 
meeting concluded. 


SAGE Working Groups 


SAGE was founded to meet the needs of people 
who administer and manage computing systems. 
As the organization grows, we want to have a 
clear vision of just what those needs are and how 
they should be addressed. In that Ught, working 
groups were formed at the June SAGE meeting. 

Each group is chartered to discuss a topic of inter¬ 
est and determine if it is a viable candidate for 
action on the part of SAGE. The working groups 
can recommend against pursuing a topic further. 
If you have strong feehngs in either direction, you 
are encouraged to join a group and present your 
opinion. If determined to be viable, the working 
group will draft a proposal for the SAGE board 
which outlines possible methods of addressing 
the issue at hand. 

Below is the list of working groups current as of 
June 25. Listed are the name of the group, the 
leader, the email address that the working group 
will be using, and then a paragraph describing 
some of the topics and goals the group will 
attempt to address. If you are interested in joining 
one or more of these groups, send email to 
<listserv@usenix.org> with a body message of 
"help" and you will be sent further information 
to subscribe to the various lists. 


1. Conferences and Workshops - Steve Simmons 
sage-conf@usenix.org 

The conferences and workshops group will focus 
on public activities of both academic and practi¬ 
cal use for systems administration, including 
involvement in the USENIX LISA conference. 

2. Publications - Bryan McDonald 
sage-pubs@usenix.org 

The publications group is chartered to put to¬ 
gether a series of proposals related to the various 
pubhcations that SAGE wants established. In the 
immediate future the pubs group will be asked to 
assist in the publication of the first issues of news¬ 
letter segments within this newsletter. Long term 
goals include proposals concerning an indepen¬ 
dent newsletter, a technical journal, software tool 
collections, and any other ideas the committee 
can collect. 

3. Electronic Information Distribution - Mark Verber 
sage-oniine@usenix.org 

The electronic information distribution working 
group will identify existing information sources 
that would be of use to SAGE members, new 
types of information that should be gathered, 
produced, and make proposals for the effective 
distribution of this information. Existing sources 
should include reprints of papers/articles and 
mailing-list/USENET news archives. New infor- 
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mation sources might include specially written 
technical/positional papers and custom data¬ 
bases such as vendor neutral lists of bugs. Distri¬ 
bution methods will include WAIS or other 
information servers, anonymous ftp/uucp, and 
CD-ROM. 

4. Education -Pat Wilson - sage-edu§usenix,org 

The education working group's initial goal is to 
outline possible plans for institutional and con¬ 
tinuing education of the community through the 
development of model curricula, the identifica¬ 
tion and promotion of useful tutorial programs, 
and the construction of guides for self-study. 

5. Certification - Paul Moriarty 
$age-certify§ usenix.org 

The purpose of the certification working group is 
to address the issues surroimding certification 
and discuss the various approaches that might be 
taken. The working group will present the model 
along with their recommendations to the board of 
directors. 

6. Job Descriptions - Tina Darmohray 
sage-jobs§u$enix.org 

The job description group will evaluate SAGE's 
role in assisting system administrators with 
defining job descriptions. If it is determined that 
this is an area that SAGE should pursue, the focus 
of the group will be to create multiple system 
administration job description suites that can be 
used as templates for those who are writing po¬ 
sition descriptions for hiring purposes at their 
own site. 

7. Awards - John Detke - sage-robbies@usenix.org 

The awards working group will focus how SAGE 
can best go about recognizing outstanding sys¬ 
tem administrators, and their achievements. Ini¬ 
tial suggestions include a "Best of LISA" award 
and an annual outstanding sysadmin award. 

8. Public Relations - Paul Evans 
sage-pr@usenix.org 

As a professional society, SAGE has the opportu¬ 
nity to speak out to many factions of industry 
and/or government on issues that affect us and 
our profession. This committee will examine the 
issues, set guidelines for SAGE's involvement in 
this area, and (if appropriate) determine a plan or 
focus for the guild to evaluate and pursue (or not 
pursue). This group will also serve to direct any 
future public relations issues that may arise, 

9. Local Groups - Bjorn Satdeva 
sage-iocals@usenix.org 

This group will have the task of exploring how 


the creation of new local groups can be made eas¬ 
ier, how SAGE and USENIX can assist in their for¬ 
mation, and how SAGE can support existing local 
groups. 

10. Ethics-Ed Gould 
sage-ethics@usenix.org 

This group is charged with determining SAGE's 
role in developing a set of guidelines or codes of 
ethics for the system administrator. We see these 
guidelines or codes as having at least two pur¬ 
poses, namely, guiding one's self in the perfor¬ 
mance of system administration tasks, and 
informing one's employer and co-workers of the 
proper bounds of system administration. 

11. Policies-Lee Damon 
sage-poHcies@usenix.org 

The focus of the policies working group is the 
consideration of one or several documents for 
system/network administrators to use as guide¬ 
lines or boilerplates in setting up their site's poli¬ 
cies and procedures. We will also be working 
with the education and ethics working groups to 
help systems administrators understand just 
what policies are, and why they can be important. 

12. Vendors - Terry Bartlett 
sage-vendors@usenix.org 

The vendor working group will evaluate SAGE's 
role in establishing a consensus on the types of 
tools we'd like vendors to provide for system and 
network administration. The group may also act 
as a vendor lobbying organization to convince the 
various manufacturers to "do the right thing" 
when it comes to system administration. 

13. Standards - Janet Frazer 
sage-stds@usenix.org 

The standards working group wiQ evaluate the 
potential for SAGE to monitor and affect the var¬ 
ious standards bodies that are currently or will be 
in the future setting standards for system admin¬ 
istration. 

14. Non-UNIX - John Detke 
sage-outreach@usenix.org 

The non-UNIX outreach working group will 
focus on how SAGE can remain pertinent to peo¬ 
ple who manage computing systems and net¬ 
works, addressing the issues that cross operating 
and network system boundaries. 

15. Part-Time Admins - Peg Schafer 
sage-pt@usenix.org 

The part-time working group is concerned that 
the proposed SAGE charter did not mention the 
large number of people who do system adminis- 
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Part-Time Admins (cont.) 

tration less than 100% of the time (e.g., there are 
chemists who fulfill system administration roles 
some portion of each working day; yet, they view 
themselves as chemists, not system administra¬ 
tors). We will consider how SAGE could address 
the needs of such individuals and propose 
changes to the proposed SAGE charter which 
address this "dual-role" reality. 


16. Security - Laura de Leon & Arnoid de Leon 
$age-security§usenix,org 

Security is a growing concern for system admin¬ 
istrators. This group will examine ways of help¬ 
ing system administrators assess their need for 
security and security policies. We will seek ways 
to educate system administrators on security 
issues. We will consider soliciting or developing 
sample policies and tools in this arena. 


SAGE Book Reviews 


by Steve Simmons 

<scs@lokkur.dexter. mi. us> 

What the world needs is a good book on the 
hardware side of ethemets - installing, expand¬ 
ing, maintaining, and debugging. Unfortu¬ 
nately there is no such beast. This review will 
discuss two publications which cover the phys¬ 
ical side of ethemet. 

Keeping The Link by Martin Nemzow. McGraw-Hiii, 
1988, ISBN 0-07-046302.366 pages. Hardcover. 

This book covers the physical end of various fla¬ 
vors of ethemets. It contains a great deal of 
good material, as well as some non-technical 
material which can safely be ignored. It has 
some deficiencies, but is quite useful in spite of 
them. 

It is excellent at covering the purely physical 
and technical topics. Its most valuable feature is 
the detailed treatment on the physical handling 
of an ethernet. It includes step by step instruc¬ 
tions with photographs and drawings on a 
number of topics, including: how to make taps; 
how to debug physical and electrical problems 
using TDRs and various other test equipment; 
(the section on TDRs includes photographs 
showing the traces from various sorts of ether- 
net hardware in both proper and defective 
operation); and drawings and pictures of vari¬ 
ous common cables and other connection hard¬ 
ware. 

From this book, I was able to correctly install a 
thick ethernet transceiver, having never seen 
the tools before. 

In addition to the excellent instmctions, it is rich 
with diagrams, charts, and tables of physical 
constants. They're often worth as much as the 
text. It also contains a number of sample forms 


and recommendations for managing the physical 
cable plant. These should all be of great use to any 
working administrator. 

Unfortunately, it has a number of problems. 
Nemzow is a firm behever in broadband ethemet 
and gives it equal play with thicknet, Cheapemet, 
and thin ethemet. He discusses fiber, but at a 
much lower level of detail; lObaseT is almost 
completely ignored.Given that the book was 
written in 1988, these last two points are some¬ 
what forgivable, but the lack of data on lObaseT 
lengths is particularly fmstrating. 

Nemzow spends a great deal of time talking 
about the usefulness of networks. This material is 
not needed, appropriate, or accurate. Fortunately 
it's easy to skip over. 

In summary, this is easily the best of what I've 
seen on the hardware-side of ethemet manage¬ 
ment. It is not a great book, but nonetheless is a 
valuable addition to your library. A second edi¬ 
tion with updates could be a major seller. 

Telecommunication Wiring by Clyde N. Herrick and C. 
Lee McKim. Prentice-Hall, 1992, 

ISBN 0-13-151531-4.253 pages. Hardcover. 

I ordered this on the basis of a flier from Prentice- 
HaU which touted it for the physical end of com¬ 
puter network management. The back cover reit¬ 
erates this claim. Unfortunately, the contents do 
not hve up to the claims. 

This book has major flaws for anyone using it as 
a guide for computer network installation. It 
repeatedly mentions using coaxial wiring for 
cable TV, mentions that ethernet runs over coaxial 
cable, but never mentions that the two require 
different sorts of cable. 

Similar problems can be found with the tele¬ 
phony wiring sections. No mention is made that 
one might want to wire telephony systems some¬ 
what differently from lObaseT or RS-232. 

In short, this is a most disappointing book for the 
computer network management and I do not re¬ 
commend it. 
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SAGE Membership Form 


Yes, I would like to join the USENIX special technical group SAGE, the Systems Administrators' Guild, 
as follows: 

[ ] I am a current USENIX member. I wish to join SAGE. Enclosed is $25 to cover dues for the 
remainder of 1992. My membership number is_. 

[ ] I am not a current USENIX member. I wish to join USENIX and SAGE. Enclosed is $90 
($65 for a one year individual membership in USENIX; $25 for SAGE dues for 1992). 


Name - - 

Address_ 

City _ _ State_ Zip_Country 

Phone _email address:_ 


PAYMENT OPTIONS 

□ Check enclosed payable to USENIX Association or SAGE. 

□] Please charge my: Visa Q MasterCard ^ 

Account # Exp. Date 


Signature _ 

Outside the U.S.A.? Please make your payment in U.S. currency by one of the following: 

* Charge (Visa, MasterCard, or foreign equivalent) 

* International postal money order 

* Check - issued by a local branch of a U.S. Bank 


USENIX Mailing List 

□ I do not want my address made available to other members. 

□ I do not want my address made available for commercial mailings. 

Please mail this form to: USENIX Association 

2560 Ninth Street, Suite 215 
Berkeley, CA 94710 
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Simmons’Laws of System Administration 


by Steve Simmons 

<$cs@lokkur.dexter.mi.us> 

The Definition: 

System Adrcunistration is the combination of sys¬ 
tem support and user support. 

The First Law of System Administration; 

Any rule can be modified by the application of 
power and policy. By contrast, rules always are 
subordinate to laws. 

The Network Paradox; 

System support is a subset of network support. 
Network support is a subset of system support. 

The Laws Of Unanticipated Support Cost; 

1. It will always cost you more to support a thing 
than the vendor told you. 

2. It will usually cost you more to support a thing 
than to buy it. 

3. Sometimes it costs lOx as much to support a 
thing as it did to buy it. 

4. Refusing to support something often results in 
the thing being unusable, 

5. Once it's installed, supporting a thing is some 
times cheaper than not supporting it. 

6. Before buying, make sure you're committed to 
support. But see item 1. 

The Division Between System Support and User 
Support; 

There's a difference between system support and 
user support. There may be overlap in the two 
positions; sometimes both are done by the same 
person. But the two tasks are distinct and some¬ 
times have conflicting goals. 

The Law Of Distributed Taient; 

Great system support people often make lousy 
user support people and vice versa. 

The Paradox Of Duai Abiiities; 

The person good enough to do both system sup¬ 
port and user support will usually be hired away 
by a shop where the combined tasks are too large 
for a single person. 


On Complexity And Customization; 

Application-to-application differences confuse 
everyone, especially users and support staff. 

Ditto UNIX-to-UNIX differences, etc. By contrast, 
complete consistency completely stifles improve¬ 
ment. At any given site for any given application 
or feature, there's someone who knows more 
about it than the support staff. Finding that per¬ 
son is the first step to take to diagnose any given 
problem. 

Tune to diagnose and time to fix are completely 
imrelated. Sometimes one approaches zero while 
the other approaches infinity. This is especially 
hard to deal with when the diagnostic person and 
the fix person are not the same. 

One person's improved feature is another per¬ 
son's gratuitous change. 

Users want applications and systems they can 
customize. 

One user's customization is another user's gratu¬ 
itous change. 

The Laws Of The Cost Of Customization; 

The cost of customization is complexity. The cost 
of complexity is increased difficulty in adminis¬ 
tration and user support. The cost of increased 
difficulty in administration and user support is 
either lower quality of administration and user 
support, increased support staff, or both. There¬ 
fore, increased customization means increased 
cost, or lower quality of support, or both. 

The Paradox Of Unused Customization: 

It doesn't matter whether customization has actu¬ 
ally been done. The mere fact that it's possible 
means you must check for it, thereby increasing 
the cost of problem diagnosis. 

Smailwood's Law (Simmons' paraphrase); 

^'They're not users, they're clients." Kevin Small¬ 
wood. 

Users Are Human: 

The user who says "Can X be done?" is usually 
really asking "Would someone please do X?" 
Make sure you answer both questions. It's human 
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to blame problems on outside causes. By contrast, 
an outsider will always suspect the insider as the 
cause. 

The user who says "I didn't change anything" 
isn't always lying. Sometimes they're just igno¬ 
rant or forgetful. 

It's more important for users to do their job than 
to answer the needs of admins. Unless of course 
their job is to answer that need. 

Admins Are Human: 

For every statement in "Users Are Human/' 
change "user" to "admin" and vice-versa. 

The ‘You Broke It’ Principle: 

Cockpit error is the most common cause of prob¬ 
lems. Everybody is a pilot. 

Support Is Overhead: 

One way of cutting costs without cutting devel¬ 
opment staff is by cutting overhead. System 
administration and user support are overhead. 

User and system admin training are overhead. 
Not having them increases overhead. Go figure. 

The Joy Of Being A Contract System Administrator: 

"Sure, we can do that. Here's what it'll cost you." 

His Site Isn’t Your Site: 

The situation at your site doesn't make you qual¬ 
ified to judge the situation at another site, and 
vice-versa. 

Just because someone else's support staff does it 
doesn't mean your staff can do it. (This statement 
is subtler than it looks.) 

The Rules of Policy and Power: 

1. System administration is whatever the boss 
tells the admins it is. 

2. Users will bypass admins to get the boss to tell 
the admins something different. That's their 
right. 

3. Most system admins live in a policy vacuum. 
This can be good or bad: 


Corollary 1: 

Power expands to fill a vacuum. That thing 
which expands most easily is a gas. 

Corollary 2: 

Anything that quickly expanded to fill a vac¬ 
uum is easily displaced by a solid. 

Corollary 3: 

A rapidly moving solid will hurt you if 
you're in its way. The person who does your 
job review makes the rules. The good admins 
always follow those rules. See Rule 1 and the 
First Law. 

The Summary: 

Be careful what you do in that vacuum. Nobody 
appointed you God. However, you can always be 
disappointed. 

The Laws Of System And Network Growth: 

You can always incrementally add one more. 

Sometimes the straw breaks the camels back. 
More often, the camel just goes slower and 
slower. 

The difficulty of support does not grow linearly 
with the size of the site. 

Eventually your site outstrips your methods, and 
you must bite the bullet and move to new meth¬ 
ods. 

Corollary: 

Nobody bites the bullet until there's not 
enough time to do the existing work. At that 
point there's not enough time to make the 
changes. 

Adding a new kind of computer, operating sys¬ 
tem, application, peripheral, etc., has a much 
higher administrative cost than adding one more 
of what you've already got. 

Corollary 1: 

If you buy one, you may as well buy ten. 
Corollary 2: 

If you buy ten, you may as well buy eleven 
and keep one for spare parts. 
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Name Frequency on Usenet 


by Elizabeth Zwicky 

<zwicky@erg.$ri.com> 

Inspired by the ZONE (Zealot of Name Edifica¬ 
tion) data about host name frequency in the DNS 
databases, I wrote a Perl program called "'names" 
that scavenges /usr/spool/news for host and 
user names. The program attempts to get as many 
names as possible, by looking for addresses in the 
entire article. It does apply various filters; for 
instance, it recognizes Path: headers and throws 
out the last component (which is sometimes a 
user, sometimes a host, and sometimes a place 
filler Like "dont-send-mail-to-path-lines"). It also 
attempts to recognize encoded binaries (and 
ignore them) and article IDs (from which it rejects 
the "user" and saves the "host"). It stores the 
user-host pair, so that people who post multiple 
times from the same host are not multiply 
counted. 

Because of the catch-all approach, the names pro¬ 
gram has a tendency to undo the efforts of sites to 
hide individual host names and present only site 
names. This is beneficial to the host name data, 
but confounds the user name data by turning a 
single user who posts from multiple machines at 
the same site into multiple users - for undergrad¬ 
uates who post a large volume of news from 
many different machines, this rapidly becomes a 
serious problem. This is filtered by a program 
which attempts to condense hosts that a given 
user name posts from. Some duplicates remain, 
mostly from single hosts on multiple networks, 
and a few hosts are incorrectly condensed, but the 
result appears to be considerably more accurate 
than the imcondensed data. For a user like me 
who appears at "pterodactyl.erg.sri.com", 
"sparkyfs.erg.sri.com", "erg.sri.com", and 
"sparkyfs", it will condense the whole lot down 
to "erg.sri.com". 

The host name counts just look at each imique 
host name. This will result in some duplication 
for hosts that appear as "host", "host.com" and 
"host.uucp". The program's trusting nature also 
causes it to take example addresses as valid, 
which probably explains the popularity of "host" 
as a host name. (It does not fuUy explain why 
"nodomain" is a more popular domain than 
"domain", however.) 

An option to the program allows it to accumulate 
data over time; I have spent several days letting it 


run every night out of cron to add new names. 
This uses disk space, memory, and CPU cycles 
more profligately than many people may wish to 
use them, but helps to separate the data from the 
noise. It also amuses me to watch the numbers 
move around with added data. After 10 days, I 
am averaging about 4,000 new users and 1,000 
new hosts a day. Still, I have less than a tenth as 
many hosts as the DNS data. These figures cover 
news in the spool directories on news.erg.sri.com 
between January 21 and February 10 1992. For 
those who wish to play along at home, the Perl 
scripts I used are available for anonymous FTP on 
ftp.erg.sri.com. They are both CPU and memory 
intensive, and consist primarily of uncommented 
Perl code with regular expressions that make 
Tom Christiansen's head swim. Let the FTPer 
beware. 

The most popular names are listed. There are sev¬ 
eral thousand way ties for least popular name (of 
course, truly unpopular names never occur at all, 
and there are millions of those), but I have listed 
the ones that struck me as notable. 

User Names 

Out of 114,195 users, there were 59,369 distinct 
user names. The top 50 user names: 


Rank 

# 

Name 

1 

4603 

postmaster 

2 

1628 

root 

3 

1382 

news 

4 

648 

Usenet 

5 

191 

Steve 

6 

186 

mike 

7 

179 

mark 

8 

170 

john 

9 

166 

dave 

10 

148 

paul 

11 

142 

chris 



david 

13 

133 

bill 

14 

125 

brian 

15 

124 

peter 

16 

123 

bob 



jim 

18 

118 

scott 

19 

113 

tom 

20 

112 

user 

21 

106 

dan 

22 

104 

jeff 

23 

98 

jim 

24 

97 

eric 

25 

93 

rick 

26 

88 

listserv 

27 

84 

ken 



larry 
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Rank 

# 

Name (cent.) 

29 

83 

alan 

30 

81 

joe 

martin 

michael 

33 

80 

kevin 

system 

35 

75 

marc 

36 

73 

george 

jon 

robert 

39 

72 

greg 

40 

71 

rob 

41 

69 

andrew 

andy 

bruce 

doug 

keith 

46 

66 

info 

47 

65 

frank 

48 

64 

gary 

49 

61 

richard 

ron 


The list continues similarly, with male first names 
and system accormts, until rank 94, which intro¬ 
duces the last names "anderson", "brown", and 
"johnson". At rank 133, the first exclusively 
female first name, "karen", appears. (It is of 
course impossible to teU how many of the 
instances of "pat", "lee", and so on actually 
belong to women, and how many are last names, 
"lee" and "kim" in particular may be first names 
of either men or women and are also frequent last 
names.) 

Host Names 

Host names were divided up into first compo¬ 
nents, middle components, and last components. 
(A name with only one component was consid¬ 
ered to be a lonely first component.) 

Out of 56,340 host names, there were 33,305 dis¬ 
tinct first components. These are the top 50. The 
number in parentheses is the rank from the ZONE 
information about DNS; aU names in either top 50 
are shown. 

USENET Rank ZONE Rank Name 


1 (5) cs 

2 news 

3 math 

4 cc 

5 ee 

6 pO 

7 (45) sol 

8) (9) zeus 

9 vax 


USENET Rank ZONE Rank Name (cent.) 


10 


Sim 

11 

(12) 

orion 

12 

(37) 

athena 


(20) 

sirius 

14 


vm 

15 


physics 

16 

(17) 

hobbes 

oak 

18 


eagle 

19 


helios 


(4) 

jupiter 


(10) 

mercury 


(36) 

phoenix 

ra 

24 


astro 

rigel 


(25) 

thor 

27 


chaos 

informatik 


(3) 

mars 

relay 

31 

(46) 

gandalf 


(28) 

titan 

33 

(44) 

earth 


(17) 

neptune 

vaxl 

36 


csd 


(14) 

gauss 

odin 

,turing 


(1) 

venus 

41 

(27) 

Calvin 

edu 

eng 

host 

isis 

nova 

47 


hydra 

lynx 

mail 


(26) 

merlin 


(25) 

opus 


(7) 

satum 

sunl 

54 

(32) 

apoUo 

64 

(48) 

alpha 


(15) 

newton 

83 

(30) 

hermes 


(2) 

pluto 

99 

(35) 

hal 


(6) 

iris 


(39) 

mozart 

148 

(31) 

fred 


(33) 

grumpy 


(19) 

gw 

182 

(47) 

io 


(40) 

snoopy 
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(Names with fewer than three occurrences are not 
ranked. The extra number in the following items 
is number of occurrences.) 


(8) 

0 

pel 

(11) 

0 

mac2 

(13) 

0 

mad 

(18) 

1 

pc2 

(21) 

0 

mac3 

(24) 

0 

cisco 

(29) 

0 

mac4 

(34) 

0 

mac5 

(38) 

0 

mac6 

(41) 

0 

pc3 

(42) 

0 

mac7 

(43) 

0 

maclO 

(49) 

0 

mac9 

(50) 

0 

mac8 


Some of the differences between the USENET data 
and the DNS data have obvious causes; not many 
people on Macs or PCs post news, which explains 
why names like "mad" and "pci" almost never 
appear in the USENET data. The name "pO" turns 
out to be very frequent in Fidonet addresses. 
Some of the remaining differences may also be 
minimized as the amount of USENET data grows. 
Several of the top 10 names from the DNS data 
("saturn" and "venus", for instance) did not ini¬ 
tially make the USENET top 50, and have been 
climbing steadily, "snoopy", on the other hand, 
appears to be destined to remain an also-ran. 
"elvis" is steadily climbing, and currently at rank 
73. 

A randomly chosen selection of the least popular 
machine names (there are also a few machines 
named after phone numbers); 
aethelbehrt 
air-traffic-controller 
anywhere 
apple-gunkies 
bad-loud-music 
biscuit-tin 

bopbopaloopbopawhopbamboom 

broccoli 

brussel-sprout 

computemame 

couqusmxmgus 

deathstar 

excaliber 

fnord 

globus-pallidus 

grubby-thicket 

his-phoenix-multics 

kibblesnbits 

killer-tomato 

moo 

moving-target 


national-institute-for-medical-research 

pickled-brain 

poseur 

ratmandu 

rent-a-guru 

schoolofthought 

snorkelwacker 

squid-lips 

studguppy 

toaster 

tofu-hut 

welsh_git 

Middle Components 

Everything between the first and last components 
was lumped together as a middle. Middle com¬ 
ponents have less individuality than first compo¬ 
nents, with a mere 5,788 distinct middles out of a 
total of 49,731. "zl" is another artifact of fidonet. 


Rank 

Number 

Name 

1 

1456 

cs 

2 

1250 

ac 

3 

897 

CO 

4 

695 

dec 

5 

684 

oz 

6 

634 

sun 

7 

524 

nasa 

8 

489 

hp 

9 

84 

edu 

10 

473 

fidonet 

11 

471 

cc 

12 

464 

eng 

13 

450 

berkeley 

14 

427 

enet 

15 

372 

zl 

16 

343 

mit 

17 

298 

att 

18 

288 

ibm 

19 

284 

Stanford 

20 

283 

sgi 

21 

268 

cis 

22 

266 

ohio-state 

23 

249 

uiuc 

24 

229 

emu 

25 

211 

informatik 

26 

208 

umich 

27 

200 

wise 

28 

192 

msk 

29 

177 

ge 

30 

176 

purdue 


Domain Names 


The domain name figures are consistent; al¬ 
though new domains appear as more data accu¬ 
mulates, the rank orderings have been nearly sta¬ 
ble since the first run. The second number is the 
rank for the domain in the ZONE statistics takes 
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from DNS. All domains in either top 30 are shown. 
The Soviet Union still appears in these lists, 
despite the fact that it ceased to exist nearly a 
month before I began gathering statistics. This is 
because there are still a significant number of hosts 
in the .su domain while naming settles out. 

USENET Rank ZONE Rank Name Country 


1 

(1) 

edu 


2 

(2) 

com 


3 


uucp 


4 

(7) 

ca 

Canada 

5 

(8) 

org 


6 

(15) 

uk 

United Kingdom 

7 

(5) 

au 

Australia 

8 

(3) 

gov 


9 

(6) 

de 

Germany 

10 


bitnet 


11 

(16) 

jP 

Japan 

12 

(9) 

se 

Sweden 

13 

(14) 

nl 

The Netherlands 

14 

(11) 

fr 

France 

15 


su 

Soviet Union 

16 

(4) 

mil 


17 

(12) 

fi 

Finland 

18 

(25) 

us 

United States 

19 

(13) 

no 

Norway 

20 

(10) 

ch 

Switzerland 

21 

(21) 

dk 

Denmark 

22 

(22) 

nz 

New Zealand 

23 

(23) 

es 

Spain 

24 

(17) 

at 

Austria 


(18) 

net 


26 

(19) 

it 

Italy 

27 

(26) 

be 

Belgium 


(20) 

il 

Israel 

29 


oz 

Australia 

30 


decnet 

36 

(29) 

is 

Iceland 

46 

(27) 

mx 

Mexico 

48 

(30) 

br 

Brazil 

52 

(24) 

kr 

Korea 

55 

(28) 

gr 

Greece 


Comparing coimtries represented in the USENET 
data to Don Wells' data on countries connected to 
the Internet as of January 28,1992: 

Continent Both Internet USENET 

Africa Tunisia Zimbabwe 

South Africa 

Antarctica ^ Antarctica 

Asia Hong Kong China 

1. The Antarctic belongs to no country, by treaty. The USENET 
data is based on domain extension, and since Antarctica does 
not have its own domain, it is invisible. 


Continent Both internet USENET 

Israel 
India 
Japan 
Korea 
Singapore 
Taiwan 

Australasia Australia 

New Zealand 

Europe Austria 
Belgium 
Belorus 

Czechoslovakia 
Germany 
Denmark 
Finland 
France 
Greece 
Hungary 
Ireland 
Iceland 
Italy 
Latvia 
Netherlands 
Norway 
Poland 
Portugal 
Spain 

Soviet Union 
Sweden 
Switzerland 
Ukraine 
United Kingdom 
Yugoslavia 

N. Amer. Canada 
Mexico 
United States 

S. Amer. Argentina Paraguay Cuba? 

BrazU Costa Rica 

Chile 

Other American 

Samoa? 

Netherland 

Antilles? 

Countries marked with question marks have 
hosts that I cannot identify as mistakes, but that 
are not immediately identifiable from their 
names as being bona fide, either. Errors and non- 
Intemet addresses are both common in the 
USENET data; I checked the domains by hand for 
plausibility and eliminated several dozen appar¬ 
ent countries that way. Colombia's surprisingly 
large presence on USENET turned out to consist 
entirely of .com sites with the "m" chopped off, 
for instance. 


Sri Lanka 

Nepal? 

Malaysia 
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An Update of UNIX-Related Standards Activities 


by Stephen Walli 

Report Editor '< stephe@mksxom> 

USENIX Standards Watchdog Committee 

You are in a Maze of Twisty Profiies — 

Ali Different 

[Warning — Profiles are poorly understood, ill- 
defined specifications that are being drafted as 
full standards in various corners of the standards 
community. If at first the article seems twisty and 
convoluted, that is because the topic is twisty and 
convoluted, mired in a lot of historical context. 
The article presents the historical context for pro¬ 
filing activities, and the traps lying in wait for 
unsuspecting applications developers. It finishes 
with a few recommendations.] 

Profiles are the latest confusion to appear on the 
open systems standards scene. They are sup¬ 
posed to define a view on one or more standards 
in a coherent way to fulfill a general need. This 
need may be something like: "a programming 
platform for general multi-user, multi-processing 
business applications" or maybe: "supercomput- 
ing applications typically require the following 
services." This seems reasonable. It also seems to 
feel right. So what happened? 

In the Beginning... 

The POSIX.l (ISO/IEC 9945-1:1990 == IEEE Std. 
1003.1-1990) standard standing alone is not 
enough. By its own definition, it requires C lan¬ 
guage support. This can be either Common 
Usage C or Standard C (ISO/IEC 9899:1989 == 
ANSI X3.159-1989). These two standards together 
provide a reasonable programming environment. 
They are not complete; there are many things 
missing. To move the standard forward, things 
were left out that were too contentious at the 
time. It was better to have some kind of standard 
than none at aU. 

POSIX.l also has optional functionality. Some of 
this functionality is called out by "Big-O" 
options, such as 

{NGROUPS_MAX}, LPOSIXJOB_CONTROL}, or 
(_POSIX_CHOWN_RESTRICTED}. These are imple¬ 
mentation level options, and a vendor could 
choose not to implement them and still be con¬ 
forming. There are other named options, such as 
{_POSIX_NO_TRUNC}, and {_POSIX_SAVED_IDS), 
which may or may not be implemented. A strictly 


conforming application should never count on 
such functionality being present. 

Using this simple model, the National Institute of 
Standards and Technology (NIST) created the U.S. 
government procurement document, FIPS PUB 
151-1. In it, NIST specified what options and limits 
must be supported from POSIX.l, and how the C 
language support should be done. The intent was 
to provide as functional a platform as possible by 
mandating as much of the POSIX.l standard as 
possible, something upon which U.S. govern¬ 
ment applications developers could depend. Sim- 
ple. 

A long time ago, relatively speaking, X/Open 
was formed. It described a collection of specifica¬ 
tions that aU of its member vendor organizations 
would adhere to. Thereby it provided a Common 
Application Environment (CAE) for applications 
portability. This specification of a platforms func¬ 
tionality was written down in the X/Open Porta¬ 
bility Guide (XPG). They have made a point of 
adopting POSIX standard interfaces where possi¬ 
ble, moving away from the original SVID defini¬ 
tions. Perhaps not complete, but still relatively 
simple. Both FIPS and the X/Open XPG feel kind 
of like something you, as an applications devel¬ 
oper, might want to point to when describing the 
environment you want. 

Now let's move on to where things start getting 
messy. A number of things start happening in 
parallel, which means the confusion factor goes 
up exponentially. POSIX began doing some 
things. ISO was doing others. The industry con¬ 
sortia were doing something else. And remember, 
the industry consortia are the ones backed by 
vendor money, and have a stake in selling you 
their solution. Industry consortia == A vendor 
once removed. 

POSIX 

A few years ago, at the beginning of the Great 
Project Proliferation in POSIX, two projects began 
which would develop Applications Environment 
Profiles (AEPs) for Supercomputing (POSIX.IO) 
and Transaction Processing (POSIX.il). The intent 
was to describe how to use POSIX in building 
applications in these two particular domains. In 
the last two years, two more AEP projects devel¬ 
oped in POSIX, one for Real-time applications 
(POSIX. 13) and one for Multi-processor applica¬ 
tions (POSIX.14). 
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These last two are illustrative of many of the 
problems encountered. The POSIX.4 (Real-time) 
and POSIX.4a (Threads) standards will become 
addendums to the POSIX.l base standard. All 
function interfaces defined by POSIX,4 and 
POSIX.4a will need to be provided by future 
implementations of POSIX.l, although they may 
be just stubs returning ENOSUPPORT (or some 
such), if the implementation does not support the 
added functionality. This functionality will be 
called out by named options. Hirurimm. Getting a 
little muddy. 

POSIX.13 and POSD(.14 would hopefully define 
an applications domain that must be provided by 
an implementation for the appropriate class of 
applications. By pointing at the appropriate base 
standards and choosing options, we can clearly 
define the requirements of a class of real-time or 
multi-processing applications. It is unclear 
whether the base standards are POSIX.l, 
POSIX.4, and POSIX.4a, or some future, as yet 
completed ISO/IEC 9945-1:2001. 

That's perplexing enough. Now consider the fol¬ 
lowing. POSIX.6 (Security), POSIX.8 (Transparent 
File Access), POSIX.12 (Protocol Independent 
Interfaces), POSIX.15 (Batch), and POSIX.17 
(Directory Services) functions will aU be grafted 
onto POSIX.l, with options, as they are approved. 
AU of these base API standards, some of which 
are nothing more than option-labeUed "diffs" to 
POSIX.l (i.e., POSIX.8), wUl somehow be fit 
together into one BIG book. (And people thought 
POSIX.2 was big!) 

Remember, aU of the function interfaces wUl need 
to be provided by an implementation, even if 
only as stubs because the "option" is not pro¬ 
vided by the implementation. A portable appUca- 
tion wUl spend aU of its start-up time querying 
sysconfO to determine if the imderlying support 
is present. ProfUes, which strategic management 
believes wiU provide some wonderful shorthand 
notation to discuss procurement packages with 
vendors, wiU do nothing for the applications 
developers actuaUy writing appUcations. 

Application Environment Profiies 

I made reference to AEPs defining an environ¬ 
ment that must be provided by an implementa¬ 
tion to support an application domain. This is 
another source of confusion. Are we specifying an 
appUcation domain where the implementation 
supports far more? It likely does anyway, but in a 
non-standard fashion. Or are we specifying a 
"platform" environment, so it provides a broad 
base of functionaUty typicaUy required by an 
application domain. I believe this ambiguity lies 


at the heart of the "sub-setting" problem between 
POSIX.l and POSIX.13. 

The "sub-setting" argument arises because the 
real-time AEP (POSIX,13) wants the abUity to call 
out parts of POSIX.l as options, e.g. the file sys¬ 
tem. Some people feel this is a horrible idea, since 
POSIX.l specifies a good general purpose base 
upon which to build applications. The profile 
specifiers, however, don't need the rest of the 
standard to describe their application domain. 
This has been a constant source of argument and 
confusion in the POSIX world. What can a profile 
point to, and how? 

And then there are other specifications, outside of 
POSIX and TCOS, that would be obvious to 
include in certain application domain profiles. 
The POSIX.14 Multi-processing AEP would like 
to point to the X3 parallel language extensions 
work. The IEEE has no problem with pointing to 
other specifications, even incomplete early drafts 
such is the case here. It might even be an algo¬ 
rithm in a textbook. 

If the point is to define a standards based environ¬ 
ment, why would anyone want a profile standard 
to point to an indeterminate draft of a standard 
which is very unstable, even once it is mature 
enough to ballot? De facto specifications from 
vendors and vendor consortia (such as PostScript 
or OSF/Motif) are more stable than this! 

ISO, on the other hand, has very strict rules about 
what can be pointed to in a profile. This leads us 
to another fine source of information and confu¬ 
sion. Let's look at ISO's contribution. 

ISO and the OSI Stack 

ISO has a little more experience with profiles, or 
maybe one should say longer experience. If I 
understand things correctly [salt warning]: 

The ISO SC21 working groups defined the 
now famous seven layer stack. This was an 
anticipatory model, telling us how things 
should/would be done in the future, rather 
than one cluttered by implementations. 

Vendors were somewhat horrified when gov¬ 
ernments started leaning in this well defined, 
robust direction. They stiU wanted to be able 
to play in the lucrative government sandbox. 
They started demonstrating how, if you inter¬ 
pret things in one Light, their product fits the 
model here, or really fulfills these two layers 
together over there, and so on. The stack 
mutated a little. 
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The wonderful situation arose, that it was 
now possible to draw an entire path through 
the stack, top to bottom, which wouldn't 
communicate with another line through the 
stack. People even gave this a name: conform¬ 
ing incompatible implementations. 

The procurement agencies weren't too 
thrilled by this turn of events, and profiles 
were born. U.S. GOSIP (Government OSI 
Profile) specified a known implementable 
path through the maze, and they used this for 
procurement specifications to ensure that one 
government OSI installation could commimi- 
cate with another. 

So we now have this concept of a profile. Choose 
a set of API and protocol specifications that will 
work together to form the OSI conununications 
models. ISO even developed a document specify¬ 
ing how to do this. Technical Report 10000 
(TRIOOOO, or TRIOK) defines a set of rules for how 
to define an OSI profile. 

TRIOK has very strict ideas about how OSI pro¬ 
files are to be constructed, what they can point to 
and how. Profiles can only point to ISO standards 
(or other ISO profiles), if they are to have norma¬ 
tive weight. Otherwise, the references are just 
informative. 

Chaos Sets In... 

When the full complexity of this profiling prob¬ 
lem began to appear, a number of different work¬ 
ing groups began investigating the problem from 
various angles. 

The profiling groups within POSIX were identify¬ 
ing problems as they built their drafts almost 
from the time they started meeting. The groups 
operated fairly autonomously, however, and ini¬ 
tially never got together. 

Appeals were made to the POSIX.0 working 
group for help. The POSIX.O Guide to Open Sys¬ 
tems Environments defines a model for how stra¬ 
tegic management views standards being used, 
identifies many standards and where they fit into 
the model, and even has a couple of chapters on 
profiling activities and how they should be done. 
The POSIX.O working group argued, however, 
that it was not responsible for setting profiling 
policy. Go figure. 

After much pain and gnashing of teeth by the 
four POSIX profiling groups, a TCOS steering 
committee was formed to help solve the prob¬ 
lems they had been having for about two years at 
this point. The group is made up officially of one 
member from each of the working groups defin¬ 


ing profiles, and a few members of POSIX.O. 
Really. 

The Profiling Steering Committee has been meet¬ 
ing for a year now. They were immediately lost in 
a forest of liaison points, and information gather¬ 
ing, trying to determine the state of profiling in 
the world. Now to my poor naive way of think¬ 
ing, someone is not doing their job here. If the 
POSIX.O members of the PSC did not already 
have all of the profiling documents that could be 
foimd, upon what is the profiling material in 
POSIX.O based? Conversely, if they did have the 
profiling information and experience, then why 
has it taken a year to define a set of rules by which 
IEEE POSIX working groups should be defining 
profiles? 

And even with a Profiling Steering Committee, 
they were so busy investigating what everyone 
else was doing, no one noticed that the POSIX.13 
Real-time profiles were in ballot. Takes your 
breath away. 

On the ISO front, things aren't much better. True 
to their anticipatory nature of late, a few different 
groups have been formed to investigate and com¬ 
ment upon something which doesn't yet exist. 
Technical Specification Group 1 (TSGl) has taken 
a kick at the cat. 

The Special Group on Functional Specifications 
(SGFS) is also giving it a try. SGFS is attempting 
to take the TRIOK document and modify it in a 
couple of places so as to make it applicable to the 
functional API standards, such as POSIX. 

The European Workshop on Open Systems 
(EWOS), a CEN/CENELEC sponsored body, has 
set-up a working group to investigate a Common 
Application Environment (CAE). This work may 
be the most pertinent to date. There are people in 
this working group that have actually spent time 
attempting to specify real profiles in the commer¬ 
cial world. X/Open is involved in the work, lend¬ 
ing its experience with defining specifications 
such as XPG3. 

The EWOS work attempts to define a method of 
investigating the user requirements, building up 
the definitions and interfaces (informational 
rather than actual programming interfaces), and 
only a^ the very last step investigating how stan¬ 
dards might be applied to the requirements 
model. 

I was careful in the last paragraph to not say what 
type of profile was being defined. There is stiU a 
lot of discussion with respect to what is an appli¬ 
cation environment profile, versus a platform 
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environment profile, and there is even a new con¬ 
cept of a component profile. There is grey, and 
then there are shades of grey 

Wrap Up 

> GET SENSE 

I SEE NO SENSE HERE. 

> XYZZY 

XYZZY DOES NOT WORK HERE. 

> DROP THE BIRD 

Where do we go from here? 

Profiles are poorly defined specifications (despite 
the many attempts at writing rules for their cre¬ 
ation,) based for the most part on unstable docu¬ 
ments in ballot, and there is no real experience at 
defining and implementing formal profiles in the 
open systems world. (The OSI profiles appear to 
be a well-defined, well-structured set of specifica¬ 
tions which developed after there was experience 
with the stack — not before.) 

Why do people feel that these documents should 
be standards? Why build castles on foundations 
of sand? We do NOT know what shape some of 
the key standards will be in until they finish bal¬ 
lot. Simply pointing to an interim draft of a docu¬ 
ment in ballot, even if the IEEE is willing to 
archive the draft, is silly. 

The point is to specify an environment (applica¬ 
tion specific or not) which applications develop¬ 
ers can count on. These environment 
specifications are supposed to be standards 
based. That's the whole point! The draft docu¬ 
ments in ballot will change. Saying we'll modify 
the profile standard later, when the base docu¬ 
ments complete ballot, is naive! People will have 
used it in procurements. Applications will have 
been written. What if the functionality in the base 
standard is gone? Or mutated so as to be useless 
to the profile? What's the rush for a useless stan¬ 
dard? 

There is the desire to specify how a set of stan¬ 
dards can be used together to define a known 
environment to solve a set of applications porta¬ 
bility problems. The simple extremes of a single 
standard profile (FIPS PUB 151-1), or a suite of 
specifications (X/Open's Portability Guide), have 
proven to be useful. It is useful for people to put 
down on paper the definition of a set of require¬ 
ments for a particular applications domain, as is 
described by documents like the EWOS CAE 
working group's work. This should be done in a 
less formal way. 

The Paul Masson Method should be applied. (We 
will define no standard before its time.) Make the 


profiling work either "guidelines" or "recom¬ 
mended practices" at the IEEE level, or "technical 
reports" at the ISO level. Until people have REAL 
experience putting these complex, subtle API def¬ 
initions together with appropriate other func¬ 
tional and language standards, many of which 
are still in ballot or under definition, profiles 
should not be given the weight of full standards. 

If you're an application developer, get involved. 
FoUow the POSIX mailings. Determine what your 
national standards organization is doing. Ask 
questions, or make yourself heard through your 
institutional representatives to POSIX. (USENIX, 
EurOpen, Uniforum, DECUS, CUG, and SHARE 
are aU represented in IEEE TCOS. X/Open, Unix 
International, and the OSF are also present.) 

Before some strategic thinking manager above 
you makes the decision for you, you should fuUy 
appreciate the enormity of the confusion being 
unleashed on you as you quietly contemplate that 
POSIX.l and ANSI C are probably useful after all. 

Report on POSIX.O: Guide to Open Systems 
Environments 

Kevin Lewis <klewis@gucci.enet.dec.com> reports on 
the April 8-12,1992 meeting in Dallas, TX: 

As I reported in the January Snitch for POSIX.O, 
the POSIX Guide to Open Systems Environments 
(OSE) is going to formal ballot (finally, as someone 
in the SEC said to me...). If you are in the TCOS 
Balloting Pool, you should have received an invi¬ 
tation to join the ballot group for this work. 

The formal ballot will be on draft 15 which is 
being produced presently. The changes submit¬ 
ted by the group to produce this draft strictly 
addressed the mock ballot comments. The group 
agreed (after I placed a gag order on them) not to 
surface or open any issues that had previously 
been considered closed. This went a long way 
towards our moving through the comments and 
objections. (By the way, if you were one of our 
mock balloters, please be patient. I will be send¬ 
ing out a summary along with detailed baUot res¬ 
olutions after I have completed the formal ballot 
package for IEEE.) 

The formal ballot closure date has not yet been 
determined, although it appears that the end of 
August is the likely time frame. Our goal is to 
have a significant number of ballot responses into 
IEEE and the ballot coordinator (i.e. me) prior to 
the October meeting in Europe so we can use that 
time for ballot resolution, as well as share the 
results with our European counterparts. 
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Two issues remain as we move toward formal 
ballot. One is a rationale document. It became 
apparent during the April meeting that our 
attempts to use our Issues Log, along with the 
minutes and institutional memory of the core 
participants of the group, were lacking when it 
came to actually documenting our rationale for 
certain issues. So the July meeting has been dedi¬ 
cated to the task of developing and writing this 
document. 

The other issue is that of public specifications. 
Our document is moving into the international 
formal standards forums. Looking out to the hori¬ 
zon, we expect there wiU be a lot of consternation 
over the group's choice to include informal spec¬ 
ifications in the guide. 

This wiQ undoubtedly shape into another battle 
of significant proportions. The formal ballot 
period should offer the current warriors a chance 
to take a breather. 

Report on P0SIX.1; System Service API 

Peter Collinson <pc@hillside.co.uk> reports on the 
April 8-12,1992 meeting in Dallas, TX: 

[Ed. — Peter is the USENIX Institutional Represen¬ 
tative to TCOS-SS, the IEEE group responsible for 
drafting the POSIX family of standards.] 

Overview 

Theoretically, I spent most of the week in POSIX.l, 
the working group for the "original" system 
interface standard. It's still meeting because it has 
several extant projects: 

POSIX.lLIS, programming language indepen¬ 
dent POSIX.l; 

POSLK.ie, the C binding to POSIX.lLIS; 

POSIX.la, the place where bug fixes and new 
features for POSIX.l are being put while the 
language independence work is being done; 

POSLX.IS, the POSIX Environment Profile. It's 
a profile (or list of other standards) intended 
to describe something close to a complete 
UNIX system. 

I tend only to attend the work for the first of these 
because I also go to many other steering commit¬ 
tee meetings. Here's an idea of what happened in 
the bits that I managed to get to .... 

The Report... 

The ISO standards working group on POSIX, 


WG15, requires that the IEEE POSIX working 
groups produce a programming language inde¬ 
pendent version of the existing POSIX.l standard 
(ISO 9945-1). This language independent specifi¬ 
cation (LIS) is referred to as POSIX.lLIS. 

The POSIX.l standard has been re-cast in two sec¬ 
tions: the language independent specification 
and a C language binding (POS1X.16). The idea is 
that these two should ballot together, so that bal- 
loters can compare the original standard with the 
new pairing. 

It's planned now that the two standards wiU go to 
baUot on July 7th. This has been made possible 
because: 

the documents are close to being ready, have 
been mock baUoted and finaUy preened by 
the working group 

the Steering Committee on Conformance 
Testing (SCCT) has agreed that the documents 
do not need a completely new set of test 
methods written for them. They can use the 
already existing test methods for POSDC.l, 
contained in POSIX.3.1, which has nearly 
completed baUoting. 

Not needing new test methods is a great conces¬ 
sion because it avoids the rule that insists on test 
methods being available for aU new standards 
before they go to ballot. In my opinion, someone 
will need to find some funding to get the new test 
methods written. There is no enthusiasm for 
doing this in the working group. This is also the 
consensus of the group, when asked just that 
question. 

What are test methods? That's a little hard to 
explain. BasicaUy, they are terse English state¬ 
ments that assert facts about the standard. The 
idea is that these are easier to convert into pro¬ 
grams that actually test the interfaces. Each asser¬ 
tion is classified as "testable" or "not testable," 
and whether or not it applies to optional behav¬ 
ior. It's a little more complex than this. Look at 
POSIX.3 (IEEE Std. 1003.3-1991), the standard for 
test methodologies for POSIX, for more informa¬ 
tion. 

The current document drafts are based on the 
ordering in 9945-1. This is good because sections 
in aU the documents refer to the same material. If 
you are looking at Section 3.2.1 in 9945-1:1990, 
then the same material will be found in the same 
numbered section in POSIX.lLIS and POSIX.16. 

A smaU group of people who are close to the doc¬ 
ument - the editor (Hal Jesperson), the person 
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really running the LIS project (Paul Rabin from 
the OSF), and the chair of the POSIX.l Working 
Group (Donn Terry) - have realised that this is 
POSITIVELY THE LAST CHANCE to change the 
ordering of the document. [Ed. — the closeO and 
openO functions are in different chapters of the stan- 
dardr as an example.] 

Donn has come up with a potential re-ordering 
and this will be applied to the new documents. I 
was concerned that this would make balloting 
difficult, because we lose the ability to easily cross 
reference. The idea is to print a re-ordered version 
of 9945-1 (without rationale) to act as a balloter's 
aid. 

The two new documents will also contain "'other 
editorial changes." The adoption of the LIS has 
meant that the original text has been inspected 
very closely indeed, and has been found wanting 
in many places. It's often ambiguous with unclear 
wording. The text has been tightened up in these 
places. One of the tasks of the working group this 
week has been to examine a list of lines contain¬ 
ing "may," "can," "cannot," "system defined," 
and some other words to ensure that they are all 
used consistently throughout the documents. 
Where ambiguities exist the wording has been 
repaired. 

Now, you may argue that this will change the 
sense of the document, and it might. It will be up 
to the balloting group to worry about that. There 
are NO conscious changes. 

New functionality and real bug fixes have been 
held over in POSIX.la. There was no discussion on 
this during the week, because the person driving 
that, Roy McKean from X/Open, was imable to 
be in Dallas. 

Report on P0SIX.2: Shell and Utilities 

David Rowley <david@mks.com> reports on the April 
6-10 meeting in Dallas, TX: 

Summaty 

Well, it looks like it's all over but the final formal¬ 
ities. New drafts of POSIX.2 and POSIX.2a incor¬ 
porating minor editorial changes have been 
approved at the New Zealand meeting of ISO 
WG15 as Draft International Standards. They are 
Draft 12 of POSIX.2 and Draft 8.05 of POSIX.2a. 
Both POSIX.2 and POSIX.2a should go before the 
Standards Board in September for approval as 
full-use IEEE standards. 

NIST is currently working on a new FIPS (Federal 
Information Processing Standard) for POSIX.2, 


expected in draft form by early Fall 1992. 

POSIX.2b work progresses, incorporating sym¬ 
bolic link support within a number of utilities, 
and a new PAX archive format. 

Test assertion work continues, with the POSIX,2 
work adapting to an imderwhelming mock bal¬ 
lot. POSIX.2a test assertion work is well imder 
way, and appears to be easier than previously 
thought. 

Background 

A brief POSIX.2 project description: 

POSIX.2 is the base standard dealing with the 
basic shell programming language and a set of 
utilities required for the portability of shell 
scripts. It excludes most features that might be 
considered interactive. POSIX.2 also standardizes 
command-line and function interfaces related to 
certain POSIX.2 utilities (e.g., popen(), regular 
expressions, etc.). This part of POSIX.2 , which was 
developed first, is sometimes known as "Dot 2 
Classic." 

POSIX.2a , the User Portability Extension or UPE, 
is a supplement to the base standard. It standard¬ 
izes commands, such as vi, that might not appear 
in shell scripts, but are important enough that 
users must learn them on any real system. It is 
essentially an interactive standard, and will even¬ 
tually be an optional chapter to a future draft of 
the base document. This approach allows the 
adoption of the UPE to trail Dot 2 Classic without 
delaying it. 

Some utilities have both interactive and non¬ 
interactive features. In such cases, the UPE defines 
extensions from the base POSIX.2 utility. Features 
used both interactively and in scripts tend to be 
defined in the base standard. 

POSIX.2b is a newly approved project which will 
cover extensions and new requests from other 
groups, such as a new file format for PAX and 
extensions for s 3 anbolic links. 

Together, Dot 2 Classic and the UPE will make up 
the International Standards Organization's ISO 
9945-2 - the second volume of the proposed ISO 
three-volume POSIX standard. 

POSIX.2 Status 

Draft 12 of POSIX.2 has been prepared, a minor 
revision of Draft 11.3 to take care of some editorial 
concerns fir ISO WG15. This new draft will form 
the final POSIX.2 standard, expected to be 
approved at the September meeting of the IEEE 
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Standards Board. Draft 12 has also been ap-proved 
by ISO WG15 as a Draft International Standard. It 
is certainly a help to implementors to have both 
the IEEE and ISO versions of the Shell and Utility 
standard coordinated in this manner. 

P0SIX.2a Status 

In a similar fashion to POSIX.2 Classic, a minor 
revision of POSIX.2a has been prepared to address 
some minor ISO editorial concerns. Draft 8.05 (so 
named to reflect the extent of the changes) wiU 
form the final POSIX.2a standard, and should also 
be approved at the September meeting of the IEEE 
Standards Board. This draft has also been 
approved by ISO as a Draft International Stan¬ 
dard. 

FIPS and Certification 

Now that NIST is preparing a new FIPS for 
POSIX.2 and POSIX.2a, the issue of conformance 
testing and certification ^s rearing its contentious 
head once again. The problem is one of timing and 
organization. NIST of course wishes the certifica¬ 
tion suite to be based on the POSIX.3.2 test meth¬ 
ods work. However, it has only just gone to mock 
ballot, and is still quite a distance from comple¬ 
tion. The POSIX.2a test methods work has only 
recently started. In spite of this, NIST wishes to 
put forth a FIPS now in order to encourage the use 
of the standard within the US Government. Unfor¬ 
tunately no standard metric for gauging conform¬ 
ance will exist for some time. NIST's lack of money 
for test suite efforts is causing a number of vendors 
concern and frustration, causing other solutions to 
be investigated. If you would like up to date infor¬ 
mation on the current status of POSIX.2 conform¬ 
ance testing, please feel free to drop me a note. 

PAX File Format 

The new file format for PAX is progressing, but the 
group is still not completely convinced that the 
ISO 1001 tape format is the best technology to base 
the format upon. No alternatives have been put 
forth, so the group will likely continue along the 
current path until someone makes a coimter-pro- 
posal. 

One issue decided at the Dallas meeting was the 
codeset to be used within the archive to represent 
filenames. The 16-bit plane of Unicode/ ISO 10646 
(UCS2) has been selected as a good reference set of 
glyphs which should suit the needs of the vast 
majority of users. A step up to UCS4, the 32-bit 
version, will be plarmed for in the format. Gary 
Miller (IBM), POSIX internationalization and 
codeset guru, has given his blessing to the 
approach. 


Test Methods 

The POSIX.3.2 Test Methods for POSIX.2 mock 
ballot did not go well. Hardly any comments 
were received, so the group spent the Dallas 
meeting in small groups, one group working on 
creating ballot objections, and another on ballot 
resolutions. This isn't how it's supposed to work, 
folks. It is critical that the test methods work has 
the same level of broad-based input that the 
POSIX.2 standard enjoyed. Although the skill set 
required to effectively ballot the document is spe¬ 
cialized and rare, the effort needs as much input 
as possible. 

The document will go out of mock ballot for a 
while imtH a plan to get reasonable feedback has 
been formulated. 

Work on the POSIX.2a test methods also pro¬ 
gressed. The earlier fears of the difficulty of creat¬ 
ing assertions for the interactive commands (i?z, 
talk, etc.) have proven to be largely unfounded. 
However, turrdng the assertions into a test suite 
may still be a challenge. 

Report on P0SIX.3: POSIX Test Methods and 
Conformance 

Andrew Twigger <att@root.coMk> reports on the 
April 6-10,1992 meeting in Dallas, TX: 

SCOT Matters 

Once again, the Steering Committee for Conform¬ 
ance Testing (SCCT) met for three sessions during 
the week. During the first session, Roger Martin 
(Chair) announced that three new members had 
been invited to join the SCCT. These are Jerry 
Powell (IBM), Stephe Walli (MKS) and Dan 
Hegerty (US Navy). The four remaining members 
of the SCCT (Roger Martin, Lowell Johnson, 
Andrew Twigger, and Bruce Weiner) were 
appointed for a further two year period. 

The SCCT realised that unless it became more 
pro-active in encouraging the POSIX working 
groups to meet their test method development 
plans, the groups would not complete this work 
item. There had been a marked drop in the 
requests to the SCCT for test method consultancy 
from the working groups. It was believed that, in 
several cases, test method development was 
being sidelined while other issues were 
advanced. The SCCT decided that it needed to 
monitor progress more regularly and to advise 
the Project Management Committee in cases 
where slippage became evident. 

The SCCT also became involved in discussions 
about the production of test methods for lan¬ 
guage independent specifications (LIS). [Ed - 
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Don't groan people. This stuff has real value.] This 
was discussed in the context of the POSIX.l LIS. 
The thinking goes as follows: 

Language Independent Specifications are 
useful. They provide the functional specifica¬ 
tion upon which programming language 
syntax is layered in the language's most nat¬ 
ural form. The intent is to allow different lan¬ 
guages to bind as easily as possible. 

Real implementations support the function¬ 
ality described in the language independent 
functional specification through language 
bindings. Real implementations are only 
valid through real languages, and can only be 
tested using real languages. 

In the same way that the functionality behind 
each language binding is the same, the test 
assertions are for the most part fimctional test 
assertions. There are additional syntax 
related assertions for each language, but a 
large percentage are functional assertions. 

By expressing the assertions as functional 
assertions written to the LIS standard, real 
test cases in different languages can be writ¬ 
ten. [Ed — think about the problem of verifying a 
POSIX.5 (Ada) run-time implementation.] 

The initial target for LI test assertions was the 
revised POSIX.l LIS, which is expected to enter 
ballot in the next quarter. The SCCT decided that 
they would accept POSIX.ILIS entering ballot 
with a reference to the current POSIX.3.1 C lan¬ 
guage binding assertion set, but that LI test asser¬ 
tions would be needed before ballot could 
complete. 

At the moment there seems to be little interest in 
producing the LI test assertions — the task was 
described as a further layer of boredom on top of 
an already boring task! However, the SCCT 
believe that there is considerable value to those 
working groups who are amending POSIX.l to 
develop a set of LI test assertions and this really 
needs a base set of assertions from POSIX.l LIS. 

Test Methods for P0SIX.1 

POSIX.3.1 is the test methods document for 
POSIX.l, the base operating system service inter¬ 
face, During the meeting the technical reviewers 
worked to resolve the remaining objections 
against draft 13 of this standard. It is believed that 
all of the outstanding objections have now been 
dealt with, and that the document is ready for a 
final recirculation ballot. It is hoped that this will 


be completed by the end of June and the docu¬ 
ment forwarded to the standards board shortly 
afterwards. 

Test Methods for P0SIX.2 

The POSIX.3 and POSIX.2 working groups met 
jointly for most of the week with the available 
members from each of the groups starting to 
review the current draft document. This exercise 
caused many of the members of the group to rea¬ 
lise how many areas still needed to be addressed, 
and at the end of the week a plan was put 
together to provide enough input to the technical 
editor to allow a much more complete draft to be 
produced. 

Concurrent with this task, a few members of the 
POSIX.2 working group continued with the spec¬ 
ification of test methods for POSIX.2a (LFPE). 
Most of the work on the simpler utilities was 
completed, but the larger utilities still need to be 
tackled. 

Report on POSIX.5; Ada Binding to P0SIX.1 

Del Swanson <dswanson@email.sp.unisys.com> 
reports on the April 8-12,1992 meeting in Dallas, TX: 

The POSIX.5 group has been working to produce 
Ada language bindings to POSIX standards. So 
far, we have been concentrating on the POSIX.l 
standard and the Real-time Extensions standards 
being developed by POSIX.4. There are informal 
plans to prepare a project request (PAR) to 
develop an Ada binding to POSIX.2 as weU. 

The big excitement at the Dallas meeting was that 
Draft 8 had been produced in a short time, fixing 
minor problems in Draft 7, and was sent out for a 
fast recirculation. This draft was overwhelmingly 
approved, and Draft 9, encompassing a few edi¬ 
torial changes, is being submitted to the Standard 
Review Board for its final approval as an IEEE 
standard. [Ed. — Del informs me that POSIX.5 has 
been approved as an IEEE Standard by the Standards 
Board on June 18. Congratulations to all who worked 
on and balloted the document!] 

Meanwhile, the group proceeded blithely along 
with its new task, to develop an Ada binding to 
the Real-time extensions being balloted from 
POSIX.4. Three position papers had been pre¬ 
pared, and were presented to the group, on the 
relationship of Ada runtime library functionality 
and the Real-time extensions. The issues were 
outlined in the report of the last meeting. 

The group was fortunate to be presented with a 
draft thin binding to POSIX.4, which had been 
prepared at Florida State University under con- 
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tract to the U.S. Army. The group divided up the 
document, and individuals presented analyses to 
the group. The task for the POSIX.4 Ada binding 
group appears to be a cooperative effort with FSU, 
which should speed the process significantly. 

Everyone agreed that the binding to POSIX.4 will 
be relatively straightforward. The POSIX.4a 
(Threads) binding, however, will have more sig¬ 
nificant problems. 

Currently we are proceeding with the Ada bind¬ 
ings to the Real-time extensions in the same man¬ 
ner used for the POSIX.l binding, i.e., working 
from the C language interface. By TCOS fiat, the 
binding will ultimately be to the Language Inde¬ 
pendent Specification of the POSIX.4 documents. 
The hitch is that the Real-time extensions group is 
just recently moving beyond its initial experi¬ 
ments with LIS, done in early 1990. The pieces are 
all finally in place, with an LIS of POSIX.l and its 
C-binding (POSIX.l6), to start the work seriously. 
At the April session, there was significant interac¬ 
tion between the two groups, to try to make the 
transition smoother. 

Two issues in particular were addressed. First, 
the POSIX.5 working group composed a list of ele¬ 
ments of the C binding which we thought partic¬ 
ularly needed to be made language neutral, and 
discussed them with the Real-time group. Sec¬ 
ond, since it was agreed that ideally the names of 
the LIS should be reflected in all the language 
bindings, we provided to POSIX.4 a list of identi¬ 
fiers which seemed appropriate for the functions. 

We have also supplied to POSIX.4 a draft of the 
thin Ada binding to what we have projected as an 
LIS. The hope is that seeing the results of a bind¬ 
ing to an LIS wiU provide some guidance for the 
development of one. 

We are expecting that within a couple of more 
drafts the current thin binding to POSIX.4 wiU be 
in good condition. We are meanwhile dividing up 
the responsibilities to start on sections of POSIX.4a 
and POSIX.4b. It is still a bit early to project a real¬ 
istic date for beginning balloting. 

Report on P0SIX.17- Directory Services API 

MarkHazzard <markh@rsvhunisys.com> reports on 
the April 6-10,1992 meeting in Dallas, TX: 

Summary 

Draft 3.0 of POSIX.17 began IEEE ballot on April 
7th and finished the first round of balloting May 
19th with 84% of the ballot group responding. We 
completed sending responses to all who partici¬ 
pated in the Mock Ballot of Draft 2.0. 


The group formed a ballot resolution team, and 
dealt with the "Which track to ISO?" issue. Split¬ 
ting/re-casting our Project Authorization 
Request (PAR) was a hot topic. We're following a 
PMC recommendation to separate the Directory 
Services API work (which is in ballot) from the 
POSIX name space issue which hasn't received 
much attention. 

Introduction 

The POSIX.17 group has defined and is balloting 
a user to directory API (e.g., API to an X.500 DUA 
- Directory User Agent). We used APIA — 
X/Open's XDS specification as a basis for work. 
XDS is an object oriented interface and requires a 
companion specification (XOM) for object man¬ 
agement. 

XOM is a stand-alone specification with general 
applicability beyond the API to directory ser¬ 
vices. It is used by IEEE P1224.1 (X.400 API) and 
is being standardized by the P1224 working 
group. 

The current POSIX.17 PAR has a two part scope. 
The first authorizes the group to work on an API 
to directory services. The second (and more con¬ 
tentious) part addresses the POSIX name space 
issue. The working group has discussed name 
space, but decided to focus on the API to direc¬ 
tory. 

POSIX.17 is one of five "networking" groups 
under TCOS, and comes under the purview of the 
Distributed Services Steering Committee (DSSC). 

Status 

The group finally completed aU the written 
responses to the comments received from the 
Mock Ballot of Draft 2.0 of our document. If you 
responded, you should have a reply by now. 

Draft 3.0 of POSIX.17 was distributed for IEEE 
ballot just prior to the Dallas meeting, and 
included all test methods and the language inde¬ 
pendent specification (LIS). The document grew 
from 234 pages in Draft 2.3 to 478 pgs in Draft 3.0 
with the inclusion of all remaining test methods. 

As of this writing, the 1st ballot is now officially 
closed, with 84% of the Ballot Group returning 
ballots. 

Once again, we met with POSIX.12 (Protocol 
Independent Interfaces) in joint session and dis¬ 
cussed their requirements on directory services. 
The white paper produced by POSIX.17 was used 
as a basis for moving ahead on requirements. 
(The white paper was the result of an action taken 
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in Irvine to document agreements, assumptions, 
issues, options and proposed actions.) 

The meeting was quite productive and resulted in 
an understanding on how to progress the work. 
POSIX.17 took an action to assist the POSIX.12 
group with writing an armex mapping a simpli¬ 
fied, more focused interface to the POSIX.17 API. 

Some POSIX.17 members met with P1224 to pro¬ 
cess the comments/objections raised during the 
initial round of balloting of the object manage¬ 
ment specification. 

The PMC recommended in January that the 
POSIX.17 project request (PAR) be split into two 
separate projects, one for the Directory Services 
API work (which is in ballot) and the other for the 
POSIX name space issue which hasn't received 
much attention. 

Name space conjures up many different things 
for different audiences. Some folks see the issue 
as a language issue, dealing with function pre¬ 
fixes and the like. The working group sees the 
issue as one in which objects are uniquely named 
in a global context, i.e. beyond a single kernel. If 
we use the process id as an example, we find that 
the 5-digit positive integer used as the name for a 
process within most kernels doesn't scale too weU 
globally. If I want to have a utility that determines 
the status of aU my processes, even those on other 
kernels, I have to somehow extend the name 
space. 

There was a spirited debate as to whether or not 
a second PAR was needed for name space work, 
in that the issues could be resolved by some other 
mechanism in the TCOS realm. Neither POSIX.17 
nor the System Interface Coordination Commit¬ 
tee (SICC) believe that POSIX.17 owns the "C" 
name space issue. A white paper wiU be pro¬ 
duced summarizing the name space issue and the 
work to date. Stay tuned ... 

The road to ISO 

The group spent much time debating how to 
progress the POSIX.17 API work for ISO stan¬ 
dardization. The central point of contention was a 
proposal to remove the POSIX.17 API from ISO 
9945-1 to join P1224/P1224.1 in a to-be-deter- 
mined track in ISO. [Ed. — ISO/IEC 9945-1 is the 
ISO name for IEEE 1003.1, or POSIX.l. All other sys¬ 
tem interfaces, such as POSIX.4 real-time and 
POSIX.6 security, are supposed to be integrated to 
9945-1 in future ammendments.] 

The rationale given was that since the POSIX.17 
work is dependent on P1224 and aU three docu¬ 
ments share the same style of interface and roots. 


they should all be progressed to ISO within the 
same Working Group. Since P1224 and P1224.1 
aren't part of (and won't be part of) 9945-1, 
POSIX.17 should be pulled out of 9945-1 and pro¬ 
gressed with the other two documents. 

There is a risk that ISO SC22/WG15 (the ISO POSIX 
Subcommittee 22 Working Group) will not 
accept a work item for an API to directory ser¬ 
vices outside of 9945-1. The implication is that a 
new SC22 working group (or one from SC21 or 
SC18) may be required for this work, with aU the 
associated start-up overhead. All this could delay 
the work and subsequently jeopardize its com¬ 
pletion as an ISO standard. 

Taking the work from 9945-1 also breaks the link 
requiring a distributed POSIX system to include 
an API to directory services. At least one other 
distributed services working group (POSIX.12) 
was concerned about this as well. 

Arguments against the non-9945-1 track to ISO 
resulted in a compromise that will (hopefully) 
allow us to retain the reference to the POSIX.17 
work in a work item for 9945-1. The work item 
could revert to a pointer to the work being done 
outside of 9945-1 (if that comes about) and also 
serve as a place holder for our work within SC22 
WG15 if another track couldn't be foimd. 

A resolution was prepared for the SEC, proposing 
that the SEC authorize POSIX.17 to take several 
actions relating to the mechanics of progressing 
our document through the IEEE ballot process 
and on to ISO. After some initial tough sledding 
late Thursday night, (my Minnesota roots show¬ 
ing), the SEC accepted all the time critical aspects 
of the resolution, deferring the rest until Chicago. 

In Closing... 

Once again, there are quite a few homework 
assignments between meetings. The ballot reso¬ 
lution process begins. Look for a white paper 
rationalizing the directory services API work 
with the name space issue. We also need to sub¬ 
mit a New Project proposal for progressing the 
POSIX.17 to ISO within SC22. 

The group will meet next time in Chicago, con¬ 
centrating on Ballot resolution and name space 
issues. We plan to meet in Utrecht and possibly 
for a few days in Reading, UK, to complete the 
work for our first (and hopefully final) ballot 
recirculation. 
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Report on P1224; X.400API 

Steve Trus <trus@duke.ncslnist.gov> reports on the 
April 8-12,1992 meeting in Dallas, TX: 

Summary 

P1224 is the Object Management API, based on X/ 
Open's Object Management specification (XOM). 
It is used by POSIX.17 (Directory Services API) 
and the P1224.1 document. P1224.1 is the X.400 
API. 

P1224 spent a productive meeting in Dallas, and 
we are very near the completion of the standard¬ 
ization of the P1224 and P1224.1 documents. 

At the Dallas meeting we: 

1. discussed our goals for the International 
Standardization of the IEEE Networking APIs, 

2. planned future work for the P1224 group, 

3. presented the status of the IEEE balloting of 
P1224, 

4. presented the status of the IEEE balloting of 
P1224.1, 

5. planned the recirculation of the P1224 docu¬ 
ment, and 

6. resolved ballot objections and reviewed bal¬ 
lot comments for the P1224 document. 

International Standardization of the networking APIs 

We discussed options for the International Stan¬ 
dardization of the networking APIs. The goals of 
the P1224 group are to have our work standard¬ 
ized with minimal changes in JTCl, and to have 
the X.400 and the POSIX.17 Directory Services 
APIs standardized in the same JTCl Subcommit¬ 
tee. 

P1224 Working Group Future Plans 

Plans for standardizing future X.400 related APIs 
were discussed. The X.400 API Association and X/ 
Open will have stable base documents for a P7 
and an EDI API by the end of 1992. Tentatively, we 
would Hke to begin converting these documents 
into IEEE standards at the January 1993 meeting. 

P1224 Status 

Balloting of the P1224 document began January 1, 
1992, and ended January 31. The ballot group 
consists of 73 members. The P1224 ballot closed 
with 87% of the ballots returned, and 75% of the 
eligible voters approved the document. The test 
methods for P1224 will be included in the first 


recirculation of the document. (Balloting cannot 
complete until the test methods are balloted.) 

The group spent two days resolving ballot objec¬ 
tions and reviewing baUot comments for the 
P1224 document. The technical editor will incor¬ 
porate the changes and the test methods into the 
document. 

We agreed to limit the recirculation objections 
and comments to changes to draft 4 of the P1224 
document and test methods. Recirculation begins 
May 17,1992 and it will end Jime 19. 

P1224.1 Status 

The P1224.1 balloting period will begin May 6, 
1992 and will end June 5. There are 49 people in 
this balloting group. The test methods will be 
included in the initial ballot of the P1224.1 docu¬ 
ment. 

Iain Devine, the P1224 technical editor will be the 
ballot resolution reviewer, assisted in technical 
matters by members of the X.400 API Association 
and X/Open. 

In Closing... 

The progress of the P1224 working group is very 
good. We hope to have the P1224 and P1224.1 
standards complete by the end of 1992. The pri¬ 
mary function of the July and October meetings 
will be P1224 and P1224.1 ballot resolution. 

Report on The IEEE Standards Board 

An Anonymous Friend ofUSENIX reports on the 
March 1992 meeting. 

[Ed—Anyone wishing to send comments to the report 
writer may do so through me.] 

The March 92 meeting of the IEEE Standards 
Board contained some very interesting action on 
the GUI project authorization requests (PARs), 
more forward (or backward) movement on other 
TCOS (POSIX) PARS, and broad developments in 
the IT (Information Technology) field in general. 

X3/JTC1 U.S. TAG merger 

One of the big discussion items on last year's 
Board agendas was the proposed merger of X3 
with the ISO/IEC JTCl U.S. TAG (U.S. Technical 
Advisory Group for ISO/IEC Joint Technical 
Committee 1). Considered to be an administra¬ 
tive advantage for both organizations, and a 
means to speed up the possible mtemationaliza- 
tion of U.S. IT standards, there was concern within 
the IEEE as to how its standards groups would be 
represented in the international arena. 


40 ;login: July/August 1992 



At the March 92 meeting, it was reported that this 
merger in its current form did not achieve ap¬ 
proval through a consensus vote. It is expected 
that work will be done on the proposed merger 
and that it will reappear in a future letter ballot of 
the JTCl U.S. TAG (the IEEE is a member of this 
TAG). 

IT Standards Funding 

Another motion that the Board discussed is a pro¬ 
posal from ANSI to charge "'participants" from 
the U.S. in international standardization efforts a 
fee to cover the administrative costs of handling 
the international IT standards activities. Remem¬ 
ber, ANSI is the member body representing the 
U.S. in ISO. (For the lEC, its a group called the U.S. 
National Committee, or U.S.N.C). The Board cre¬ 
ated an ad-hoc committee to address this. This 
committee held its first meeting during Board 
week and explored guidelines and processes to 
come up with a response to this request. Gary 
Robinson and John Rankine are the Computer 
Society representatives on this committee. 

Cray Users Group 

Cray Users Group requested Organizational Rep¬ 
resentative status at this Board meeting and, with 
the recommendation of the TCOS chair, was 
approved as an OR by the Board. 

TCOS Inside Track on RevCom 

One of the TCOS vice-chairs, Lorraine Kevra, is 
now on the IEEE Standards Board Review Com¬ 
mittee (RevCom), which gives recommendations 
for final approval of standards to the Board. Lor¬ 
raine will be able to bring first-hand experience 
with this back to TCOS and, hopefully, be able to 
explain the convoluted existence of POSIX to Rev¬ 
Com!! 

The next IEEE Standards Board meeting will be 
June 16-18 in San Juan, Puerto Rico. The follow¬ 
ing meeting will be September 15-17 in New York 
City. The deadline for submission of PARs and 
standards for the September meeting is August 7. 

NesCom (New Standards Committee Activity) 

NesCom set a new record for work, with over 75 
PARS on their agenda. The meeting went for over 
six hours. If you could ever imagine a completely 
exhausted committee, NesCom was it at the end 
of their day! 

Approved New TCOS Projects 

P1003.7.1 (OS) Standard for Information Technol- 
ogy—Portable Operating System Interface 
(POSIX)“Part 3: System Administration-Amend¬ 
ment: Print Administration 


P1003.7.2 (OS) Standard for Information Technol¬ 
ogy-Portable Operating System Interface 
(POSIX)-Part 3: System Administration-Amend¬ 
ment: Software Administration 

P1003.16a (OS) Standard for Information Technol- 
ogy-POSIX C Language Interfaces -Part 1: Bind¬ 
ing for System Application Program Interface 
(API)- Amendment 1: System API Extensions 

Approved TCOS PARs to Revise Existing Standards: 

P1003.2b (OS) Standard for Information Technol¬ 
ogy-Portable Operating System Interface 
(POSIX)-Part 2: Shell and Utilities 

Approved TCOS Revised PARs: 

P1003.1 (OS) Standard for Information Technol- 
ogy-Portable Operating System Interface 
(POSIX)-Part 1: System Application Program 
Interface (API) [Language Independent] 

P1003.1a (OS) Standard for Information Technol¬ 
ogy-Portable Operating System Interface 
(POSIX)-Part 1: System Application Program 
Interface (API) [Language Independentj- 
Amendment 1: System API Extensions 

P1003.7 (OS) Standard for Information Technol¬ 
ogy—Portable Operating System Interface 
(POSIX)-Part 3: System Administration Interface 

P1003.16 (OS) Standard for Information Technol¬ 
ogy— POSIX C Language Interfaces-Part 1: Bind¬ 
ing for System Application Program Interface 
(API) 

P1201.1 (OS) Standard for Information Technol- 
ogy-Uniform Application Program Interface- 
Graphical User Interfaces 

TCOS PARS for Which Approval Was Withheld 

There was one imapproved TCOS PAR: 

P1003.19 (OS) Standard for Information Technol- 
ogy—POSIX Fortran 90 Language Interfaces—Part 
1: Binding for System Application Program Inter¬ 
face (API) 

Ths project was not approved because the scope 
did not clearly imply that this standard would 
not change the existing language standard pro¬ 
duced in X3. The amended PAR was not filed in 
time for the June Board meeting; let's hope for 
September! 

PARS Removed From the NesCom Agenda: 

P1295.1 (see) Standard for Information Technol- 
ogy—X Window System—Modular Toolkit 

P1295.2 (sec) Standard for Information Technol - 
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ogy—X Window System-Open Toolkit Environ¬ 
ment 

These PARs (the GUI PARs) were removed from 
the NesCom agenda per NesCom member John 
Horch because the Sponsor-approved wording 
changes were not available in time for the Nes¬ 
Com meeting. They will be reintroduced at the 
June Board meeting. 

[Ed. — The Standards Advisory Board has apparently 
withdrawn the offer of hosting the sponsorship of the 
GUI PARs from TCOS. The supporters of the Open 
Toolkit Environment and Modular Toolkit PARs 
(Motif and Open Look by different names), have con¬ 
vinced the SAB their destiny lies elsewhere. 

This is despite the fact that they fall within TCOS's 
scope statement, and that the P1201 windowing PARs 
lie within TCOS.] 

Report on ANSI X3J11 and ISO/IEC SC22I 
WG14; C Language 

Michael Meissner <meissner@osf.org> reports on the 
May 10-15,1992 meeting in Salt Lake City, UT: 

On May 10-12 of 1992,1 attended the ANSI X3J11.1 
meeting, and on May 13-15 of 1992,1 attended the 
combined ANSI X3J11 and ISO WG14 meetings. 

For those people who aren't aware of how the 
various committees interact, and what their char¬ 
ter is, here is a thumbnail sketch. In the beginning 
was the ANSI X3J11 committee, which is the 
American committee chartered to produce a C 
standard. The first C standard was approved in 
December of 1989, and is available as X3.159- 
1989. The X3J11 committee is now doing interpre¬ 
tations, where they have to answer queries about 
the standard, but cannot change it. 

Around 1988, the ISO WG14 committee was 
formed to lead the American C standard through 
as an international standard. In ISO, each coimtry 
gets one vote, and the USA votes through ANSI. 
After reformatting the standard and moving 
some sections around to meet ISO guidelines, the 
C standard was approved as an international 
standard, which is available as ISO/IEC:9899- 
1989(E). 

At the time the standard was approved, there 
were three open issues raised by Japan, Denmark, 
and England, and there was approval to work on 
a normative addenda to address the problems. 
(These issues are covered later.) 

Aroimd 1989, some people started meeting to dis¬ 
cuss numerical issues and the C language. The 
committee, originally called NCEG (Numerical C 


Extension Group), has since become X3J11.1, a 
subcommittee of X3J11. Their charter is to pro¬ 
duce a technical report, which does not have the 
weight of a ANSI or ISO standard. I suspect many 
of the X3J11.1 features will be items to be consid¬ 
ered for the next ANSI/ISO C standard. This com¬ 
mittee is made up of various interested parties 
who care about floating point calculations. 

X3J11.1 

X3J11.1 met for the first three days, from May 10 
through May 12. 

I went to the floating point extensions subgroup 
on Sunday night. For the most part, this meeting 
was imcontroversial. The floating point exten¬ 
sions group had submitted their draft to a letter 
ballot which passed, and the meeting was used to 
address minor editorial changes and comments 
from the ballot. The draft contains the following 
items: 

New syntax for floating point constants, so 
that you can specify the exponent and man¬ 
tissa in hexadecimal, rather than decimal. 

Printflscanf%dil%A format specifiers to print 
the floating number in the new hexadecimal 
format. 

More math functions. 

Overloaded math functions — these func¬ 
tions are a step towards C++ style overload¬ 
ing: if the arguments are single precision, the 
calculation is done in single precision. Unlike 
C++, these are only required for the system 
functions and not the user functions. 

Requirements on exactly when Nan/Infin- 
ity/-0 is produced from the various match 
functions if the system uses IEEE 754/854 
floating point. (Most systems these days use 
IEEE 754 format). 

Adding IEEE unordered comparisons (!>, 
etc.) which return true if either value is a Nan, 
instead of false. 

Adding floating point classification func¬ 
tions. 

Ways to get/set exception flags. 

Two new include files are added. 

On Monday and Tuesday, I went to the normal 
X3J11.1 meetings. The following items were dis¬ 
cussed: 
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The restricted type qualifier proposal had a suc¬ 
cessful letter ballot, and will go outside of X3J11.1 
for review. This proposal is halfway between the 
current situation where the compiler can't fully 
vectorize, and noalias, which got shot down 
before the standard went out. It adds a new qual¬ 
ifier, restricted, which says that you promise that 
the given pointer is the only way a particular item 
is referenced. This will allow a function to take 
two restricted pointers, and to fully vectorize the 
accesses, because the compiler doesn't have to 
worry about overlap cases. 

Automatic variables with variable dimensions 
were discussed, but no conclusion was reached. 
There are two proposals on the floor, one from 
Cray and the other from USL. The Cray proposal 
would require people to pass the boimds explic¬ 
itly for arrays, and has problems in scoping if the 
boimd is passed after the array The USL proposal 
which is authored by Dennis Ritchie, would pass 
a "fat" pointer, which is a descriptor that contains 
the bounds as well as the pointer. The debate 
went on as to which was more in the spirit of C. I 
personally tend to favor the USL proposal. 

Designated initializers will go out for a review. 
These allow a programmer to initialize a struc¬ 
ture or array out of order. For example: 

struct foo { 
int a, b; 

} St = { 

.b = 1, .a = 2 

}; 

int foo2[10] = { 1, [5] =2, 3 }; 

(In the array example, element 6 is initialized to 
'3'). Gcc 2.0 has a similar feature, though the syn¬ 
tax is slightly different. 

Compound literals will go out for a review. These 
allow a programmer to create an automatic (or 
static if at file scope) aggregate without having to 
give it a name, Gcc has this feature. For example: 

foo (&(struct bar){ 1, 2 }); 

The floating point extensions draft mentioned 
earlier was approved to go out for a review. One 
item that will go in a cover letter is to warn people 
that the #pragmas specified may be changed into 
macros, since pragmas are not allowed inside 
macro expansions. 

The complex arithmetic draft was not ready to be 
sent out for review at this time. The draft needs to 
be more fully specified for IEEE floating point 
with respect to Nans and Infinities. Also, there 
was concern that the complex functions be folded 
in with the overloaded fimctions (ie, having just 


sin instead of csin). Finally, some people feel that 
in addition to real, and complex types, there 
needs to be an imaginary type that has no real 
component, particularly in the case with Nans 
and Infinities. 

There was some spirited discussion about 
extended integers and 64 bit machines. The 64-bit 
consortium (vendors who will be producing 64 
bit CPUs) want the ANSI group to exactly specify 
what sizes short, int, long, etc. are in 64 bit envi¬ 
ronments. Given that ANSI committees typically 
take years to come down from the mountain, and 
the 64-bit consortium needs to deliver products 
soon, it was hopeless. Also, there are good rea¬ 
sons why the standard only gives miiumums. The 
crux of the problem is that when you move to 64 
bits, programs will break (just like they did in 
moving 16 bits to 32 bits, but there is more extant 
code in C now). No matter what you choose, you 
break somebody's cherished notations. One camp 
wants int, pointer size, and long to all be 64 bits, 
and there is no explicit 32 bit type. Another camp 
wants int to be 32 bits, and pointers/long to be 64 
bits. Finally at least one person wanted int to be 
64 bits and long to be 32 bits. The C committee 
roimdly reviled any rule that broke the rule that 
sizeof (int) <= sizeof (long), but otherwise had no 
comments to send back to the 64-bit consortium. 
The array syntax subgroup met on Monday 
night. This group is charged with doing things to 
arrays, so that fast code can be generated on the 
vectorizers and/or massively parallel machines 
(essentially Cray vs. Thinking Machines). 

The meeting quickly broke down into shouting 
matches and such. I felt that it made negative 
progress, to the point that the only positive vote 
was a "motherhood" vote on the group's charter. 
There was another array syntax subcommittee 
meeting on Tuesday night (and possibly Wednes¬ 
day night also), but I declined to attend 

NSIX3J11/IS0 WG14 

On Wednesday through Friday (May 13 -15), the 
ANSI X3J11 and ISO WG14 met together. At times 
the meeting was run in ANSI X3J11 mode, and at 
other times it was in ISO WG14 mode. The pri¬ 
mary objective for the ANSI part of the meeting 
was to answer questions about the standard. The 
primary objective of the ISO part of the meeting 
was to deal with the three proposed normative 
addendum. 

The U.K. addendum is designed to tighten up the 
wording of the standard, but not to make any 
substantive changes. The goal of the Japanese 
addendum is to add additional wide character 
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functions and a new header in which to declare 
thera. The Danish addendum provides alterna¬ 
tives to the ANSI trigraphs, while not using any of 
the national replacement characters from ISO 646. 

The big news is that the ANSI C standard will 
soon be withdrawn and replaced with the ISO C 
standard, so that the standards remain synchro¬ 
nized. This means that chapter and verse quota¬ 
tions will soon change, due to paragraph 
renumbering required by ISO. Also, when the 
normative addenda come out, they will become 
part of the ANSI C standard, in addition to the ISO 
C standard. 

Some of the decisions reached in talking about 
the Japanese addenda include: 

Wide character I/O functions can return 
errors if they can't translate multibyte <-> 
wide characters. Errno is set to CEILSEQ 
upon such an error. 

If a wide character value is 
>= 0 and <= UCHAR _MAX, then the single 
byte character classification functions 
{isprintO, isspaceO, etc.) if true, implies that 
the wide version {iswprintO, iswspaceQ, etc.) is 
also true. If the single byte version is false, it 
does not imply that the wide version also 
returns false. This is to allow wide characters 
to fill up positions in the encoding that aren't 
valid single byte values. 

We voted against adding more support for 
mixing multibyte and wide character strings 
in the *printf()j^scanf() family of functions. 
The proposal was for %hs to always mean 
multibyte characters in both printfO and 
wprintfO, %ls would always mean wide 


characters, and %s would mean either multi¬ 
byte or wide characters, depending on 
whether the fimction was printfO or wprintfO. 

The new function wcswcsO (wide version of 
strstrO), got renamed to wcsstrO, since most 
people felt that the second 'str' represented 
substring. 

We voted not to reserve the wide stdio func¬ 
tions for a future standard to put in stdio.h 
(ie, you always have to include wchar.h to 
properly declare those functions). 

We voted that no illegal multibyte sequence 
will be emitted by the wide character output 
routines (including through %S or %C in 
printfO). 

We voted that only a single byte space termi¬ 
nates scan! ( ' ' %S' ' ) / ie. not iswspaceO, to 
allow for logically ungeting just a single byte. 

The Danish digraph proposal was shot down 
(again). I suspect it may be for the last time, 
because more countries are concerned about 
delaying the rest of the addenda for this one small 
issue. Japan and the Netherlands both voiced this 
opinion for the first time at this meeting. 

There will be letter ballots sent out on the various 
responses to interpretation requests. One letter 
ballot will cover all decisions in which there were 
no "no" votes at the committee, and one letter 
ballot will be sent out for each decision that had 
at least one "no" vote. It is hoped that the draft for 
the document of interpretation requests will be 
passed in the letter ballot, so it can be sent out for 
the next meeting (6 months from now). 
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ISO Monitor Report 


ISO Monitor Report on the May 1992 ISO 
POSIX Meeting 

by Stephen Walli 

<stephe@mks.com> 

Overview 


Currently, the IEEE POSIX.4 (Real-time), POSIX.6 
(Security), and POSIX.8 (Transparent File Access) 
documents are all somewhere in the WG15 
review-and-comment process. These documents 
will all be rolled (as programming language inde¬ 
pendent functional specifications) into 9945-1. 
POSIX.2 and POSIX,2a will become 9945-2 in the 
(relatively) near future. POSIX.7.1 (Printer 
Adrninistration) is making its debut on the ISO 
WG15 scene this meeting in a very informal way, 
as the WG15 members were encouraged to join 
the initial mock ballot. This book will eventually 
become part of 9945-3. 


The International Standards Organisation (ISO) 
and the International Electrotechnical Commis¬ 
sion (lEC) jointly develop international standards 
for information technology The family of IEEE 
standards known as POSIX are being brought for¬ 
ward as international standards. 

The ISO view of this process is that the standards 
are being developed by a national body (U.S.) 
instead of the more traditional model of ISO 
working group development. (Similar national 
body development is going on for C-i-i- in 
JTC1/SC22/WG21 which meets jointly with 
ANSI sponsored X3J16.) The IEEE forwards work 
through an ANSI sponsored Technical Advisory 
Group (TAG), to ISO/IEC JTC1/SC22/WG15. 
This frightfully long agglomeration of acronyms 
stands for ISO/IEC Joint Technical Committee 1 
QTCl), Subcommittee 22 (SC22) on Programming 
Languages, Working Group 15 (WG15) on POSIX. 

WG15 (as we shall refer to it) helps guide the 
IEEE documents as they come forward as ISO 
standards. Direct development of the documents 
does not happen in WG15, but rather it acts as a 
focal point for international comment and much 
of the Liaison work that is required to ensure that 
the IEEE documents will be able to stand as ISO 
standards. 

The point of the process is to develop a single 
standard which does not diverge from the IEEE 
counterpart. The groups have succeeded to date, 
with the base operating system API embodied by 
IEEE Std 1003.1-1990 being identical to ISO/IEC 
9945-1:1990 with the minor exception of the plain 
white ISO book cover. The IEEE Standards Press 
even produces the ISO book, and they do so on 
A4 paper no less! 

The WG15 projects are organised into three stan¬ 
dards: 9945-1 represents all of the operating sys¬ 
tem APIs, 9945-2 represents the shell and utilities, 
and 9945-3 wiU be the system administration 
functionality. 


The last thing worth mentioning before getting 
into the report of this meeting is the group itself. 
There were 21 attendees. (The IEEE typically has 
around 350 attendees.) This number is a Uttle low, 
as we were meeting on the other side of the globe 
in New Zealand. These 21 people represented 9 
coimtries (one country gets one vote.) Size of del¬ 
egation is always fun to note. (Please see the 
table.) 

Country Count IEEE 


U.S. 4 

Canada 4 

England 2 

Germany 1 

France 1 

Italy 1 

Japan 1 

Denmark 1 

New Zealand 4 

Officers 2 

9 21 


4 

2 

2 

1 


2 

11 


The officers are the convener (Jim Isaak, U.S.) and 
the project technical editor (Hal Jespersen, U.S.). 
The overlap is also interesting. Jim Isaak is both 
chair of the IEEE Technical Committee on Operat¬ 
ing Systems - Standards Subcommittee (TCOS- 
SS), the group responsible for building the POSIX 
documents, as well as ISO WG15 convenor. Hal 
Jespersen is also TCOS-SS Vice Chair of Technical 
Editing, and chair of IEEE POSIX.2 (Shell and 
Utilities). 

The other American delegates are all voting 
members of the TCOS-SS Sponsor Executive 
Committee as weU, representing the Chair of 
IEEE POSIX.l, the Chair of the Steermg Commit¬ 
tee for Conformance Testing, the Uniforum Insti¬ 
tutional Representative, and Vice-Chair of 
Logistics. One of the English delegates is Chair of 
POSIX.7 (System Administration). The German 
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delegate is Vice Chair of POSIX.6 (Security). One 
of the Canadians (the author) is the EurOpen 
Institutional Representative. 

This overlap proves useful since the size of IEEE 
POSIX (ap 350 members) makes it almost impos¬ 
sible to completely overlap the WG15 and IEEE 
TCOS-SS meetings, as the C++ people do. There 
just aren't enough horns in a day for aU the co¬ 
ordination meetings. The best that can be cur¬ 
rently done is to run one WG15 meeting a year 
right beside an IEEE meeting. WG15 meets twice 
a year. TCOS-SS meets four times a year. 

The next WG15 meeting will be in Reading, U.K., 
October 27-30,1992, following the IEEE meeting 
in Utrecht, NL, October 19-23. 

Enough of this didactic rambling. On to the 
report! 

The Meeting 

This meeting was held in Hamilton, New Zeal¬ 
and, as WG15 travelled to the far side of the globe 
m the hopes of encouraging future participation 
from New Zealand. Before everyone starts the 
"exotic locations" routine, let me point out it is 19 
hours by plane for someone from the east coast of 
North America, with a brief (2 hour stop) m a 
transit lounge. Our accommodations were under¬ 
graduate (!) dormitories at the University of 
Waikato, who hosted the meeting. You remember 
imdergrad dorms, a bed, a desk, a narrow aisle 
between them in which to dress, and the W.C. 
down the haU. The cafeteria (!!) food wasn't all 
that bad, but.... 

P0SIX.2 

One of the primary accomplishments of the week 
was the acceptance of POSIX.2 (Shell and Utili¬ 
ties) and the POSIX.2a (User Portability Exten¬ 
sion) as a Draft International Standard (DIS). 
Through the hard work of Hal Jespersen, as chair 
of POSIX.2 and the project technical editor of both 
the ISO and IEEE working groups, WG15 was 
able to settle on a draft of the documents which 
met with everyone's approval. 

The POSIX.2a User Portability Extension (UPE) is 
an amendment of the base POSIX.2 document. 
The two will be rolled together now. 

With a little luck and optinusm, the schedule 
should work something like this: 

Summer, 1992 — Final recirculation of the two 
documents in the IEEE balloting group. This will 
be similar to the final editorial circulation of 
POSIX.la as a reformatted IEEE Std. 1003.1-1988, 


just prior to becoming IEEE Std. 1003.1-1990 and 
ISO/IEC 9945-1:1990. 

September, 1992 — the two documents come for¬ 
ward to the IEEE Standards Board for final 
approval as IEEE standards (IEEE Std. 1003.2- 
1992). 

Fall, 1992 — The combined book (ap 1400 pages!) 
win be recirculated for one last ballot at the inter¬ 
national level. This ballot changes 9945-2 from a 
DIS to a full International Standard (IS). 

Because of its sheer size (volume?), there wiU still 
be ballot objections. There is just too much being 
covered to have people who are happy with all of 
it. There are still areas which have demonstrable 
problems. These can and will be fixed in future 
amendments. We are finally down to the wire for 
a document that because of the breadth of its cov¬ 
erage has been in ballot for four years. The com- 
miinity is finally going to get the companion 
standard to 9945-1 (POSIX.l) that it wants and 
needs. 

LIS 

One of the requirements placed on the IEEE 
working groups forwarding API documents as 
standards to ISO, was that they be forwarded as 
programming language independent functional 
specifications (LIS), with at least one language 
binding. The intent of this method is to allow 
other languages to bind to the fimctional specifi¬ 
cation in a maimer most natural to the language, 
and not merely re-cast the original standard's 
programming language syntax into something in 
a new language. (No one wants to propagate the 
GKS API that demonstrated that one could write 
Fortran in any language.) 

There is currently an LIS version of POSIX.l, with 
a C binding. This was built from the original C- 
based 1003.1-1990. (These documents are referred 
to as POSIX.l/LIS and POSIX.16.) They are about 
to go to IEEE ballot this Summer. 

Originally, these two new documents were to be 
an exact mapping to 1003.1-1990. The organiza¬ 
tion of the original left a little to be desired. The 
open() function and the close() function are in dif¬ 
ferent chapters. At the New Zealand meeting, 
WG15 voted to allow the POSIX.l/LIS and 
POSIX.16 technical editor to re-organize the work 
based upon a new organization agreed to by aU. 

Additionally, it was agreed that small bug fixes 
should be allowed to the documents. The timing 
of ballots is such that it could be a long time 
before another round of changes comes along to 
"fix" the POSIX.l book. 
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A concern was raised that we are opening a nasty 
hole into which many things will find their way. 
Bug fixes and wording changes (based on inter¬ 
pretations) are small. New functionality is not. 
This is something that the balloting groups will 
have to watch out for. As help for the balloter, two 
things will be added to the balloting package. 

A mini 1003.1-1990, without the rationale and 
annexes, and reorganised to the new sections, 
will be sent out to allow baUoters to see how the 
LIS and C binding align with the C-based origi¬ 
nal. 

A list of aU changes for bug fixes will be sent to 
allow baUoters to quickly locate material that has 
actually changed in content from the C-based 
original. 

A request has been made by ISO SC22/WGll 
(Language Bindings) to bring the IEEE TCOS-SS 
Guidelines document that describing how to 
buUd LIS and language bindings, forward as an 
ISO Technical Report. The new work item request 
wiU be brought forward in the FaU meeting. 

Profiling Activities 

POSIX profiling work is continuing to gain accep¬ 
tance in the WG15 arena. Profiles are seen by 
some to be the way that all the open systems stan¬ 
dards wiU be put together to form coherent work¬ 
ing environments. 

WG15 has created a Rapporteur Group for the 
Coordination of Profiling Activities (RGCPA) to 
handle activities relating to POSIX profiles within 
ISO. (Rapporteur groups are a essentiaUy a for¬ 
mal special interest group within an ISO Working 
Group, which acts as an official point of coordina¬ 
tion.) RGCPA has met twice now, once last FaU 
and again in January. 

The terms of reference for the group were estab¬ 
lished at this meeting. The RGCPA's most impor¬ 
tant role wiU be as a Uaison point for other 
profiling activities within the open systems 
world. 


The European Workshop on Open Systems 
(EWOS) has done some good work in determin¬ 
ing just how to buUd useful profiles. Luigi Ber- 
tuzzi, representing Italy at this WG15 meeting, 
has been involved in this work and presented it to 
WG15. The EWOS work involves a number of 
steps to help shape a functional profile from user 
requirements, applying standards only as the last 
step. It does not try to cram user requirements 
onto standards, nor make the mistake of assum¬ 
ing the standards represent user requirements. 

The IEEE POSIX.O (Guide to Open Systems Envi¬ 
ronments) also contains profile related work. This 
document is about to be baUoted at the IEEE 
level. POSIX.O is to be brought forward as an ISO 
technical report as well. This WG15 meeting was 
the beginning of that process. 

Internationalisation (118n) 

Internationalisation (il8n) is an obvious interest 
to an ISO standards body. WG15 created a rap¬ 
porteur group on il8n for POSIX early on in its 
existence. WG20 is another SC22 (Programming 
Languages) working group which concerns itself 
with il8n issues with respect to programming 
languages in general. Keld Simenson (DK), as a 
member of both groups, acts as the liaison in both 
directions between the groups. 

[One member quietly suggested we should really 
be concerned with intergalacticalisation. The two 
of us quickly coined the term "i20n". When we 
make first contact, remember, you heard it here 
first.] 

WG15 forwarded a liaison statement to WG20 
(Internationalisation). One of the important 
points of the statement was the recognition of the 
fact that while mtemationalising an application is 
a good thing to do, and a common portable 
method of doing so is a good thing to have, inter¬ 
nationalising an application probably reduces its 
portability. One can very quickly add a lot of 
requirements to the portability of an application 
by internationalising it. 
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The Bookworm 


by Peter H. Salus 

Sun User Group 
<peter@sug.org> 

X Window Books 

I bet there are more books on X now than on C++! 

There's that series of around a dozen voliunes 
from O'Reilly Associates (ORA) - definitely 
intended for the programmers. ORA also pub¬ 
lishes The X Resource, a quarterly made up of arti¬ 
cles and documentation otherwise totally 
unavailable. 

When I began using X11R4,1 relied on Niall 
Mansfield's The X Window System: A User's Guide. 
Last month I got Steven Mikes' X Window System 
Program Design and Development. In some ways 
this is a superior book. It is clearly written and it 
contains a great deal of information that will 
enable the relative neophyte to do work with X. 
Unfortunately, though released in January of this 
year, Mikes' volume talks about X11R4. Further¬ 
more, though Chapter 1 begins with "What is 
X?", the response ("X is the name given to what is 
becoming the de facto standard in windowing 
systems.") is not the kind of answer I had 
expected. While the sections on User Interface 
Design, Resources, Widgets, Clients, and Intercli¬ 
ent Communication appear satisfactory, arcane 
matters like V, W, or XIO don't even appear in the 
Index. This is OK as a begirmer's cook book, but 
don't expect true explanation. 

ORA was first into the fray with its Programmer's 
Supplement ofXllRS last October. We now have 
Digital Press' massive new Third Edition of X 
Window System by Robert W. Sheifler and James 
Gettys (with Jim Flowers and David Rosenthal). 
It is nearly a kilopage in length, but it appears to 
be a fairly complete reference to Xhb, X Protocol, 
ICCCM, and XLFD. Digital Press has also come 
out with Marshall Brain's Motif Programming, but 
I just don't have the time to evaluate how it stacks 
up against the Prentice-Hall volumes (which 
appear under OSF's aegis) or the ones from ORA, 

Issue #2 of The X Resource contains, among other 
things, an extremely interesting article on "Font 
Formats and Utilities" by Miles O'Neal and 
Dinah McNutt. As someone interested in print, 

I found the material on reading, converting, and 
creating font file formats most valuable. 


C++ Programming 

Whether you agree with Tom Cargill's views on 
multiple inheritance or not, there's no question 
about his abilities where C++ prograinining is 
concerned. It's a pleasure to look at his new book, 
C++ Programming Style. Modelled on Kernighan 
and Plauger's work, Cargill's book contains 
chapters on Abstraction, Consistency, Unneces¬ 
sary Inheritance, Virtual Functions, Operator 
Overloading, Wrappers, Efficiency, A Case Study, 
and Multiple Inheritance. There is also a "Sum¬ 
mary of Rules" and an Index. 

MAKE 

Mastering MAKE by Clovis L. Tondo, Andrew 
Nathanson, and Eden Yount is a pleasant small 
book . It purports to give me information on 
NMAKE (Microsoft), MAKE (Borland), and 
"MAKE on UNIX systems." Too much of the vol¬ 
ume is devoted to DOS for my taste. There are a 
few useful items here and there, but not enough 
specifically UNIX material to make the book 
worthwhile. My on-line man pages give me more 
hard information. And, unfortunately, there's 
nothing on mk or any of the other "makes" that 
are around. 

Quick Reference 

M.S. Vassiliou and J.A. Orenstein have produced 
A Computer Professional's Quick Reference. The first 
75 pages list "Common Operating System Com¬ 
mands" for UNIX (pp. 3-14); VAX-VMS (15-24); 
MVS-TSO (pp. 25-35), VM-CMS (pp. 37-43), MS- 
DOS (45-60), and Macintosh (pp. 61-76). My per¬ 
sonal feeling is that MS-DOS and Macintosh need 
more pages than UNIX, but actually I found most 
of this a waste: either one knows the commands 
or one gets a real introductory book. There is a 
nice chapter on the various ISO 8859 alphabets 
and a chapter on standards. What's there is OK, 
but don't rely on it. For example, the Usting of 
ANSI X3 committees is incomplete (it looks as 
though it was derived from the August 1989 hst) 
and the other relevant committees (like Z39) 
aren't there at all, Cargill's excellent Information 
Technology Standardization is absent from the bib¬ 
liography. Not my type of reference at all. 

Property Rights 

My guess is that everyone interested in software 
copyright, patenting, or trademarking will want a 
copy oi Finding a Balance: Computer Software, Intel¬ 
lectual Property and the Challenge of Technological 
Change, the May 1992 report from the US Con¬ 
gressional Office of Technology Assessment. 

If you've been following the various Apple or 
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Lotus suits, the FSF's documents, or attended one 
of Dan Appelman's tutorials, this badly-written 
225 page volume is for you. Written in bureaucra- 
tese by a committee, I did not find Finding the Bal¬ 
ance soporific at all. The policy issues involved in 
software copyright protection, in patent protec¬ 
tion for algorithms, and the complications faced 
by libraries in a world of ever-increasing digital 
information are discussed in detail. If Congress 
does want to do something, one of the first things 
it might do, says OTA, is clarify the scope of copy¬ 
right to either include or exclude "one or more 
aspects of software, such as" computer lan¬ 
guages, algorithms, design specifications, user 
interfaces and other interfaces. 

Congress could do this by: 

• Expanding upon the Copyright Law's current 
language on "subject matter of copyright" by say¬ 
ing that the above are or are not copyrightable 
subject material, or 

• Exempting computer programs from copyright 
and make them subject to new "sui generis" laws. 

Computer-related patents pose a special problem 
to the Patent and Trademark Office (PTO), OTA 
says, because the Supreme Court has ruled that 
mathematical algorithms may not be patented 
but processes - mcluding processes that involve 
computers - may be patented. 

On the question of whether or not the PTO proce¬ 
dures are working now, OTA concludes that they 
aren't. OTA states that the biggest problem pre¬ 
venting the PTO from carrying out its current mis¬ 
sion is dealing with prior art. PTO is forbidden 
from issuing patents unless they are "non-obvi- 
ous" to practitioners in the field and "novel" - 
that is, have never been implemented before. 

Because of PTO's problems, OTA says, patents 
have been issued that are neither non-obvious 
nor novel. 

The PTO has "serious" problems, OTA says, 
including: 

• Examiner training and turnover 

• Length of pendency periods (from filing to 
issuance for patent applications. 

• The backlog of applications 

• The quality and extent of the prior art database. 

One of the most interesting things in the report, is 
that OTA asked PTO to walk it through a typical 
software-related patent application. PTO refused. 
If that isn't an admission of just how big the PTO's 
problems are, I don't know what is. 

This is stuff that is important to all of us. If your 


congressperson is one of the few who can read, 
the problems OTA's report points out are worth 
bringing to her/his attention. 

Freebies 

I thought the best freebie I got at UniForum m San 
Francisco was The World of Standards from the 
88open Consortiiim. It is made up of just over 100 
pages of one-page summaries of things like ISO 
8348 and MIL-M-28001 and IRDS, along with refer¬ 
ences for further information, as well as summa¬ 
ries of the activities of CCITT, ECMA, NIST, etc. I 
was told that 88open would give copies away on 
a first-come-first-served basis until they ran out 
(+1 408-436-6600). 

Another worthwhile freebie, which I picked up at 
USENIX in San Antonio, is Brad Templeton's Clar- 
iNet Electronic Newspaper User Manual In addition 
to listing a number of available groups - my 
.newsrc lists over 3200 right now - Templeton has 
written a succinct guide to news and features for 
those who are afraid of the information deluge. 
Brad has told me that they give copies to custom¬ 
ers and that there might be a few available for 
prospective ones. 

The X Resource (O'Reilly & Associates, ISSN 
1058-5591) 

The X Window System: A User's Guide, Niall 
Mansfield (Addison-Wesley, 1991, ISBN 0- 
201-56344-4) 

X Window System Program Design and Develop¬ 
ment, Steven Mikes (Addison-Wesley, 1992, 
ISBN 0-201-55077-6, 304 pp.; $26.95) 

Programmer's Supplement ofXllRS (O'Reilly 
& Associates, ISBN 0-937175-86-2) 

X Window System Robert W. Sheifler and 
James Gettys (Digital Press, Third Edition, 
ISBN 1-5555-088-2,1000 pp.) 

Motif Programming, Marshall Brain (Digital 
Press, 1992, ISBN 1-55558-089-0) 

C+-I- Programming Style, Tom Cargill (Addi¬ 
son-Wesley, 1992, 225pp.) 

Mastering hAAKE, Clovis L. Tondo, Andrew 
Nathanson, and Eden Yount (Prentice-HaU, 
ISBN 0-13-554619-2,143pp.) 

A Computer Professional's Quick Reference, M.S. 
Vassiliou and J.A. Orenstein (McGraw-Hill, 
ISBN 0-07-067212-1, 266pp.) 

Finding a Balance: Computer Software, Intellec¬ 
tual Property and the Challenge of Technological 
Change, US Government Printing Office 
[OTA-TCT-527, ISBN 0-16-036188-5], $11 
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Zen and the Art of the Internet 


Zen and the Art of Internet: 

A Beginner’s Guide to the Internet 
by Brendan Kehoe 

Reviewed by Billy Barron^ 

<billy@vaxb.acs.unt.edu> 

Zen and the Art of the Internet is a new guide to the 
Internet that was written by Brendan Kehoe of 
Widener University. The author's goal is to intro¬ 
duce the reader to the resources that are available 
on the Internet while trying to avoid system spe¬ 
cific information. It should be noted that parts of 
this guide were derived from other works. 

This "book" is currently available via ftp (see 
availability below), and will be published soon by 
Prentice-Hall. 

Zen and the Art of the Internet, which starts off with 
a chapter on network basics, is a good introduc¬ 
tion to the Internet, but not a general guide to net¬ 
working. Rather, it is Internet and TCP/IP 
specific. If this chapter can be faulted for any¬ 
thing, it is that it oversimplifies some of the mate¬ 
rial. On the other hand, it definitely should not 
scare off the novice user. 

The e-mail and FTP chapters are very good, 
although they do get technical at times. The e- 
mail chapter could be improved by the addition 
of a section on etiquette similar to the excellent 
one in the FTP chapter. 

The Telnet chapter is packed with examples of 
Telnet-accessible services, and it explains how to 
find out about more services. I was rather disap¬ 
pointed by the omission of any information on 
tn3270. A description of how Telnet is different on 
IBM mainframes is also needed. These omissions 
may lead to some confusion on the part of IBM 
mainframe users. Kehoe also describes other 
tools that are available on the Internet. These 
descriptions are well-roimded and useful, but 
Kehoe has just covered the most common tools. 

One of the most outstanding sections of this 
guide is called "Things You'U Hear About." In a 
lot of ways, this chapter is a FAQ (Frequently 
Asked Questions) to the Internet, and it will 

1. This article is reprinted from The Public-Access 
Computer Systems Review 3, no. 1, witli permission. 


answer many questions asked by the new net¬ 
work user. It introduces the novice user to the 
folklore of the Internet without being intimidat¬ 
ing. 

Zen and the Art of the Internet also has useful sec¬ 
tions that contain information about commercial 
services, other networks, how to retrieve files, 
and how to find out more about the Internet. The 
USENET chapter does a great job of covering the 
most common misconceptions people have about 
that network. The document includes a helpful 
glossary. 

The conclusion states "this guide is far from com- 
plete-the Internet changes on a daily (if not 
hourly) basis." For this guide to have lasting use¬ 
fulness, it wfil need to be updated on a fairly reg¬ 
ular basis. From what I can teU, it sounds like 
Kehoe is planning to do so. I'm sending in my 
suggestions, and I recommend you do the same. 

Overall, I was very impressed with this docu¬ 
ment. In fact, the same day that I downloaded it I 
had our receptionist make copies and distribute 
them to the whole Academic Computing Support 
Staff. I am going to do the same for our library. 
I'm giving the new user of the Internet two 
sources of information to start with: the first is 
HYTELNET and the second is going to be Zen and 
the Art of the Internet. It has a few rough spots, but 
I'm sure that Kehoe will fix them. Its biggest 
problem is that it paints too rosy a picture of the 
Internet, but this kind of document is intended to 
get users interested in using the network, not as a 
critique of it. 

I try to stay ahead of most Internet users in terms 
of my knowledge of what's available and how to 
access it. Well, I learned a couple of things while 
reading this guide, so it is not just for new users. 
My message to Brendan Kehoe is: Keep up the 
good work! 

Access Instructions 

The file is available on host FTP.CS.WIDENER.EDU 
(147.31.254.132) in the directory /pub/zen and 
on FTP.UU.NET in (137.39.1,9) in the directory / 
inet/doc. Although the author reports that he has 
an agreement with a publisher, he has indicated 
that the network versions will continue to be 
available. 
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Third UNIX Security Symposium 


Baltimore, MD 
September 14-16,1992 

Sponsored by USENIX in cooperation with the 
Computer Emergency Response Team (CERT) 

The goal of this symposium is to bring together 
security practitioners, system administrators, 
system programmers, and anyone with an inter¬ 
est in computer security as it relates to networks 
and the UNIX operating system. The symposium 
will consist of a broad range of topics including 
tutorials appropriate for a technical audience, 
peer-reviewed technical presentations, and panel 
sessions. Attendees will have a unique opportu¬ 
nity to share their experiences and ideas on UNIX 
system security. 

Tutorial Program 
Monday, September 14 

Network Security; The Kerberos Approach 

Dan Geer, Geer Zolot Associates and Jon A. Rochlis, 
MIT 

Intended Audience: Systems developers respon¬ 
sible for networked workstation environments, 
particularly those whose environments may 
include networks which are not themselves phys¬ 
ically secure (i.e., "open" networks) and systems 
managers concerned about the inherent lack of 
security for managing today's network-based 
environments (e.g., UNIX's .rhosts files). 

The amazing and constantly growing numbers of 
machines and users ensures that imtrustworthy 
individuals have full access to the Internet. Given 
the increasing importance of the information 
transmitted, it is imperative to consider the basic 
security issues present as large open networks 
replace isolated timesharing systems. 

This tutorial will focus on the challenges of pro¬ 
viding security for cooperative work arrange¬ 
ments consistent with the location and scale 
independence of today's open networking envi¬ 
ronment. Attendees will gain an understanding 
of the kinds of security threats which result from 
operating in an open environment, such as one 
composed of a network of workstations and sup¬ 
porting servers. Effective approaches to meeting 
these threats wiU be presented. Although empha¬ 


sis wiU be on the Kerberos system developed at 
MIT, public key techniques for ensuring privacy 
and authentication on an open network wiU be 
explored. The X.509 authentication model and the 
new Internet Privacy Enhanced Electronic Mail 
RFCs will be discussed. 

Internet System Administrator’s Tutorial 

Ed DeHart and Barb Fraser, Computer Emergency 
Response Team 

Intended Audience: This tutorial is designed for 
users and system administrators of UNIX sys¬ 
tems, It is especially suited for system adminis¬ 
trators of UNIX systems connected to a wide area 
network based on TCP/IP such as the Internet. 
Some system administrator experience is 
assumed. 

The information presented in this tutorial is 
based on incidents reported to the Computer 
Emergency Response Team. The topics covered 
include: 

System administration - defensive strategies 

• Password selection 

• Default login shell for unused accoimts 

• Network daemon configuration 

• Verification of system programs 

• System configuration files 

• Searching for hidden intruder files 

• Staying current with software releases 

• Standard accoimting files 

• NFS configuration 

System administration - offensive strategies 

• COPS 

• /bin/passwd replacement programs 

• TCP/IP packet filtering 

• TCP/IP daemon wrapper programs 

• Security in prograrnrning 

Site-specific security policies 

• Maintaining good security at your site 

• Providing guidance to users 

• Handling incidents in an effective 
orderly fashion 

• Reviewing Site Security Policy Hand¬ 
book (RFC 1244) 

Incident handling 

• What to do if your site is broken into? 
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TECHNICAL PROGRAM 
Tuesday, September 15 
8:30 - 8:45 Opening Remarks 

8:45 -10.15 Keynote Address by Scott Charney on 
The Justice Department’s Computer Crime Initiative 

10:35-12:05 WAR STORIES 

There Be Dragons, Steve Bellovin, AT&T Bell 
Laboratories 

The Greatest Cracker-Case in Denmark: The 
Detecting, Tracing, and Arresting of Two Interna¬ 
tional Crackers, foergen Bo Madsen, The Danish 
Computing Center for Research and Education 

Experiences of Internet Security in Italy 
Alessandro Berni, Paolo Franchi, Joy Marino, Univer¬ 
sity of Genova 

1:30 - 3:00 TCP/IP NETWORK SECURITY 

An Internet Gatekeeper, Herve Schauer, Christophe 
Wolfhugel, Herve Schauer Consultants 

Network (In)Security Through IP Packet Filtering 
D. Brent Chapman, Great Circle Associates 

SOCKS, David Koblas, Independent Consultant 
Michelle R. Kolas, Computer Sciences Corporation 

3:20-5:20 TOOLS 

TCP WRAPPER, a Tool for Network Monitoring, 
Access Control and for Setting up Booby Traps, 
Wietse Venema, Eindhoven University of Technology 

Restricting Network Access to System Daemons 
Under SxmOS, William LeFebvre, Northwestern 
University 

Centralized System Monitoring with Swatch 
Stephen E. Hansen, E. Todd Atkins, Stanford Univer¬ 
sity 

Security Aspects of a UNIX PEM Implementation 
James M. Galvin, David M. Balenson, Trusted Infor¬ 
mation Systems, Inc. 

Wednesday, September 16 
9:00-10:30 TOOLS 2 

Introduction to the Shadow Password Suite, 

John F. Haugh, II, Locus Computing Corporation 

Giving Customers the Tools to Protect Them¬ 
selves, Shabbir J. Safdar, Purdue University 

ESSENSE: A Knowledge Based Security Monitor 
Linda Baillie, Gary W. Hoglund, Lisa Jansen, Eduardo 
M. Valcarce, Digital Equipment Corporation 


10:50-12:20 TOOLS 2 (cont.) 

Anatomy of a Proactive Password Changer, 

Matt Bishop, Dartmouth College 

Audit: A Policy Driven Security Checker for a 
Heterogeneous Environment, Bjorn Satdeva, /sys/ 
admin, inc. 

Secure Superuser Access Via the Internet, Darrell 
Suggs, Clemson University 

1:45 - 3:15 TRACK 1 - APPLIED RESEARCH 

Specifying and Checking UNIX Security Con¬ 
straints, Allan Heydon, DEC Systems Research Cen¬ 
ter; J. D. Tygar, Carnegie Mellon University 

A Secure Public Network Access Mechanism 
/. David Thompson, Science Applications Interna¬ 
tional Corp. Kate Arndt, The MITRE Corporation 

Network Security Via Private-Key Certificates 
Don Davis, Geer Zolot Associates, Ralph Swick, 
Digital Equipment Corporation 

1:45-3:15TRACK2-MLS 

POSIX 1003.6, Mike Ressler, Bellcore 

Is There a C2 UNIX System in the House? 

Jeremy Epstein, TRW Systems Division 

Software Security for a Network Storage Service, 
Rena A. Haynes, Suzanne M. Kelly, Sandia National 
Laboratories 

3:35 - 5:35 TRACK 1 - APPLIED RESEARCH 
(cont.) 

SunOS, C2 and Kerberos - A Comparative 
Review, Jo/zn N. Stewart, Syracuse University 

Heterogeneous Intra-Domain Authentication, 
Bart De Decker, Els Van Herreweghen, Frank Pies- 
sens, K.U.Leuven 

Observations on Reusable Password Choices, 
Eugene Spafford, Purdue University 

POSIX Report, Mike Ressler, Bellcore 

3:35 - 5:35 TRACK 2 - MLS (cont.) 

Reconciling a Formal Model and a Prototype 
Implementation: Lessons Learned in Implement¬ 
ing the ORGCON Policy, Marshall Abrams, 
Leonard LaPadula, Manette Lazear, Ingrid Olson, The 
MITRE Corporation 

UNIX Operating Services on a Multilevel Secure 
Machine, Bruno d'Ausbourg, CERT/ONERA 
France 
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Distributed Trusted UNIX Systems, Charisse Cast- 
agnoli, Charles Watt, SecureWare, Inc. 

Standards Update 

Program Committee 

Ed DeHart, Program Chair CERT 


USENIX Systems Administration 
Conference (USA Vi) 


Long Beach, CA 
October 19-23,1992 

This year's LISA conference has been expanded 
to five days (the week of October 19-23). The con¬ 
ference committee has attempted to gear the pro¬ 
gram towards system administrators from sites of 
all sizes, both large and small. 

The program will have most of the "features" of 
the USENIX main technical conferences: a termi¬ 
nal room with access to the Internet, two days of 
tutorials, three days of technical presentations, an 
"invited talks" track. Birds of a Feather sessions, 
a vendor display, and much more. 

Preliminary Tutorial Program 
Monday and Tuesday, October 19 and 20 

The LISA tutorial program will offer introduc¬ 
tory as well as advanced, practical tutorials. 
Courses are presented by skilled teachers who are 
hands-on experts in their topic areas. The LISA 
tutorial program has been developed to meet the 
needs of an audience of novice through experi¬ 
enced computer professionals. 

Attend the tutorials and benefit from this oppor¬ 
tunity for in-depth exploration and skiUs devel¬ 
opment in essential areas of UNIX system 
administration. Combining the two-day tutorial 
program with the three days of technical sessions 
give attendees the opportunity to learn from 
experts at a convenient time and at a reasonable 
cost. 

The tutorial program is divided into three tracks 
of half-day tutorials. Attendees may select from 
any non-overlapping tracks. Although some 
prior knowledge maybe needed for the advanced 


Matt Bishiop Dartmouth College 

Bill Cheswick AT&T Bell Labs 

Ana Maria De Alvare Silicon Graphics 

Jim Ellis CERT 

Barbara Fraser CERT 

Ken van Wyk CERT 

For information on hotels and registration, please 
contact the USENIX Conference office. 


tutorials, each tutorial is presented as a stand¬ 
alone class (for example, a student may take "X 
and the Administrator - part 2" without taking 
part 1 if their knowledge or experience level per¬ 
mits). 

The tutorial offerings are usually in high demand, 
and some sell out before pre-registration closes. 
Attendance is limited, and pre-registration is 
strongly recommended. 


Track 1 

Track 2 

Tracks 

Networking 

Parti 

Intro; 

PERL 

Intro: 

Sys Admin 

Part 1 

Monday AM 

X Admin 
Parti 

Domain 

Name 

System 

Intro 

Sys Admin 

Part 2 

Monday PM 

Networking 
Part 2 

Advanced 

PERL 

NEW 

Topics 

Part 1 

Tuesday AM 

X Admin 

Part 2 

Sendmail 
+ IDA 
sendmail 

NEW 

Topics 

Part 2 


Tuesday PM 

Introductory System Administration - Part 1: 

This half-day of intermediate material covers 
everything you need to know about logins (creat¬ 
ing users and manipulating the administration 
files) and backups (including short descriptions 
of the various commercial heterogeneous backup 
solutions). Additionally, the session includes an 
introduction to the problems of security at your 
site and the COPS security analysis system. 

Introductory System Administration - Part 2; 

This half-day of intermediate material covers 
setup and operation of C news; setup and opera- 
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ation of your machine roon; and setup and oper¬ 
ation of the UUCP package for connecting your 
computer to the outside world. 

Networking-Parti: 

This first half of the networking track includes an 
overview of networking and how it works; a 
description of how packets are switched through¬ 
out the internet; an introduction to transporting 
packets around your site via routers, bridges, and 
gateways; and a discussion of the new high speed 
modems and how they can foster fast, inexpen¬ 
sive communication. 

Networking - Part 2: 

The second half of the networking track concen¬ 
trates administration of users on a network. It 
includes discussions of the Network Filesystem 
and its configuration in addition to the use of 
automoimters to reduce administrative overhead 
on medium and large networks. The last part of 
the day discusses SLIP, a scheme for using serial 
lines as a low to medium speed network connec¬ 
tivity tool. 

NEW Topics in System Administration - Part 1: 

The popular 'Topics in System Administration 
Series" continues with all new material for 1993. 
The first half discusses site maintenance using 
rdist for shuttling files among many systems, how 
to organize filesystems in large, heterogeneous 
environments, source tree management for multi¬ 
ple architectures, quick configuration and instal¬ 
lation of workstations, and accoimting, 

NEW Topics in System Administration - Part 2: 

The second of the the all new material includes: 
use of daemons to increase privileges of non-root 
users, trouble management systems, text process¬ 
ing previewers, console concentrators, NNTP 
(the network news transfer program which can 
reduce netnews traffic oh your LAN), mainte¬ 
nance of large mail gateways, and electronic mail 
privacy. 

X and the Administrator - Part 1: 

This tutorial is targeted at system administrators 
who already know how to use X, but want to 
learn more about what goes on "behind the 
scenes." It includes an overview of the different 
components that make up X Windows (server, cli¬ 
ents, different vendor products, etc.). We discuss 
where the files required to run X are usually 
located and what they do. We also discuss in 
detail how to configure a user's environment 
(e.g., all the different "dot" files and environment 


variables). We then cover how to administer X ter¬ 
minals and what to look for when buying an X ter¬ 
minal. Finally, we discuss the tasks involved in 
maintaining the X source code distribution from 
MIT. There is also a troubleshooting section which 
includes hints and tips for resolving problems. 

X and the Administrator - Part 2: 

This tutorial builds on the concepts learned in part 
1 (or through experience administering X) and 
includes everything you need to know about 
fonts; useful utiiities, converting between different 
font formats, and using the X11R5 font server. We 
include discussions on using imake and how to 
manage multiple versions of X. We discuss some 
of the security issues associated with X and what 
you can do to deal with these issues. We also 
examine how to manage X in a distributed envi¬ 
ronment with multiple server and host types. 
Finally, we conclude with some advanced hints 
and tips for troubleshooting. 

Configuring Sendmaii: 

This session will concentrate on modifying, pro¬ 
gramming, and debugging sendmaii configura¬ 
tion files. Not only will syntax and semantics be 
covered but also test and verification techniques. 
The extended time wiU allow examination of sev¬ 
eral exemplary pieces of configuration files and a 
complete explication of testing and verifying 
sendmaii configuration files - including a verifica¬ 
tion suite, 

IDA Sendmaii: 

IDA Sendmaii is a net-supported, rapidly evolv¬ 
ing version of sendmaii originally based on 4.3 
BSD sendmaii. It gives the administrator the flexi¬ 
bility of direct access to dbm files (among other 
things) and comes ready to install "as is" on 
almost any system. You may want to consider IDA 
Sendmaii as the "total sendmaii solution" for your 
site. This talk covers the IDA sendmaii specifics — 
not the general problem of configuring sendmaii 
for your site. 

The Domain Name System: 

DNS, the Domain Name System, is a distributed 
database to handle hostname to IP address look¬ 
ups and to help in routing mail. This session 
includes a look at how it arose, the problems of 
scale it was trying to solve, how to configure it, 
routine maintenance and debugging. We detail 
how to set up includes, establishing primary 
server configuration, using tools for maintaining 
the forward and reverse files, configuring a 
resolver, handling MX records, and a bit about 
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designing a robust name service scheme for your 
organization. 

Introduction to Perl Programming; 

Perl is a publicly available and highly portable 
interpreted programming language occupying 
the large niche between shell and C programming, 
and as such is excellent for many system manage¬ 
ment tasks. This tutorial is suitable for individuals 
who have never looked at Perl before or have only 
just begun to use it. Students with a background in 
UNIX shell programming and regular expressions 
wiU benefit most from this course. Topics of this 
tutorial include detailed descriptions and numer¬ 
ous examples of the syntax and semantics of the 
language, its data types, operators, control flow, 
regular expressions, and I/O facilities, and using 
the Perl debugger. 

Advanced Perl Programming; 

This brand-new course is designed for program¬ 
mers already experienced with Perl who would 
like to expand their Perl expertise about sophisti¬ 
cated data types, complex networking, and 
advanced code conversion. Students with a firm 
background in both Perl and UNIX C program¬ 
ming wiQ benefit most from this course. Topics of 
this tutorial include packages to create your own 
libraries, using pointers to s)mthesize complex 
data types (such as list of lists or arrays of records), 
the bit vector data type and the selectO system call, 
using h2ph and c2ph to convert and access C code, 
socket programming, the ioctl and fcntl system 
calls, and exception handling. 

The Instructors; 

Tom Christiansen, Convex Computer Corp. 

Trent Hein, XOR Computer Systems 

Dr. Rob Kolstad, Berkeley Software Design, Inc. 

Dinah McNutt, Tivoli Systems 

Dr. Evi Nemeth, 

University of Colorado at Boulder 
Miles O'Neal, Pencom Software 
Jeff Polk, Berkeley Software Design, Inc. 


Technical Program 

Wednesday - Friday 
October 21-23 

At press time, the LISA VI abstract deadline just 
passed. The program committee is currently 
reviewing over 50 proposals for papers on a vari¬ 
ety of topics. We have received a good range of 
papers, covering most of the topics that were sug¬ 
gested in the Call For Papers, as well as additional 
ones. The committee is very pleased with the 
response to the Call and is looking forward to pre¬ 
senting a strong technical program at LISA VI. 
Here are some of the topics that are likely to be 
included in the program: 

Tools for Real-Time System Troubleshooting 
Tricks in User Education 
Graphical User Interfaces for System Ad¬ 
ministration 

Distributed System Administration 
Experiences Using Third-party Administra¬ 
tion Software 

Network Growth and Performance Manage¬ 
ment 

System Security Monitoring 
Evaluating Performance of High-End Work¬ 
stations and Servers 
Keys to Successful, Painless Upgrades 
Object Management Systems for System 
Administration 

Standardization of System Administration 
Heterogeneous System Adrninistration 
System Archiving and Backups 

If you would like to host a BOF session, have a 
suggestion for an alternate track, or need informa¬ 
tion about how your company can participate in 
the vendor display, please contact the program 
chair (see below). 

Complete information about registration and 
hotels wUl be mailed to the membership in 
August. 

Contact Information; 

Trent Hein, Program Chair 
XOR Computer Systems 
2525 Arapahoe, Suite E4-264 
Boulder, Colorado 80302 
(303) 440-6093 
<trent@xor.com> 
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UNIX Applications Development Symposium 


Call for Participation: 

Toronto, Ontario, Canada 
March 29 - April 1,1993 

Co-sponsored by the USENIX Association and Uni- 
Forum Canada. 

One of the major uses of UNIX today is the sup¬ 
port, development, and execution of applications 
ultimately used in achieving end users' business 
goals. The current trends in large end-user orga¬ 
nizations of downsizing major applications from 
older mainframes to less expensive, more power¬ 
ful, and simpler, modern networked, machines 
lend UNIX a serious position in the commercial 
marketplace. Consequently, more and more com¬ 
puting and information systems professionals are 
encoimtering UNIX when developing and main¬ 
taining applications. 

The pmpose of this symposium is to expose the 
challenges of building and maintaining applica¬ 
tions on UNIX platforms, to discuss solutions and 
experiences, and to explore existing practice and 
techniques. 

This symposium wiU feature papers, invited 
talks, panel discussions, and tutorials on aspects 
of designing, building, testing, debugging, and 
maintaining applications within and for the 
UNIX environment. There will also be ample 
opportunity at this symposium to meet your 
peers and make contact with others with similar 
interests. 

This symposium will provide valuable informa¬ 
tion to designers, progranuners, and managers 
who are planning to port existing applications 
into the UNIX environment or move develop¬ 
ment and maintenance teams from proprietary 
environments to UNIX. 

Important Dates for Refereed Paper Submissions 

Extended Abstracts Due: December 4,1992 

Notifications to Authors; December 16,1992 

Final Papers Due: February 12,1993 


Other Important Dates 

Pre-registration materials will be available in 
nud-January, 1993 

Tutorial Program 

Tues., March 29,1993 
Technical Sessions 

Wed., March 30 - Thu., April 1,1993 
Birds-Of-a-Feather Sessions 

Tues., March 29 - Thu,, April 1,1993 
USENIX Reception 

Thurs. evening, April 1,1993 

USENIX is co-sponsoring this event with UniFo- 
rum Canada, a non-profit membership organiza¬ 
tion. 

Suggested Topics: 

Topics may include, but are not Hmited to: 

Graphical User Interfaces - The X Window Sys¬ 
tem - User Interface Design & Standards. 
Open Look, Motif, NeWS, and so on. 
What is a style guide? Importance of con¬ 
sistency and ease of use. 

Porting Issues - Issues surrounding the tasks of 
porting an existing application to UNIX, 
as well as issues of making UNIX appli¬ 
cations portable to other architectures 
and other platforms. 

Networking - CHent/Server design issues, etc. 

Project Management - Using UNIX tools to sup¬ 
port project management. CASE - What, 
When, Why, Who, How. 

O/S Issues - Overcoming limitations set by hard¬ 
ware and operating systems. 

Security - The impact of security features. 

Schemes for maintaining security within 
an application. 

Transaction Processing - Implementing distrib¬ 
uted transaction processing for UNIX 
applications. 

Foiuth Generation Languages - What advantages 
and disadvantages do 4GL's have in a 
UNIX environment? 

Distributed Applications - How do you make the 
best use of existing UNIX functionality 
(such as e-mail) to build UNIX applica- 
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tions? What are the issues of building 
and/or using distributed databases? 

Object Oriented Programming - Productivity, lan¬ 
guages, techniques, case studies, etc. 

Object Oriented Databases - Advantages, etc. 

The Corporate Internet - High Speed for the Elite, 
or Connectivity for the Masses? ISDN, 
TCP/IP, OSI, UUCP. Governments, pri¬ 
vateers, service providers, co-operatives, 
telecoms. Network philosophy - open 
road, tollbooths, freeloaders or lifeblood. 
Delivering/Installing Applications - What's the 
best way? How to prevent piracy, worms, 
viruses, etc. How to do updates effec¬ 
tively and securely. 

Testing & Certifying Binary Applications - Who 
does this? What does this achieve? How 
long does it take? Applications and 
POSIX.l Conformance Testing. 

Standards - ABI/API/ANDF - How, What, 
Where, When, Why? What are they? 
How are these standards used? How do 
they affect applications? What features 
does each have? What benefits are 
derived from using each? Where should 
they be used/followed? When will they 
be real? How do you keep up with new 
standards? Why are they necessary? 

Submission Detaiis 

Papers may feature real-life experiences, as well 
as research topics. Both case-study and technical 
papers will be accepted. Case studies should 
describe existing systems and include implemen¬ 
tation details and may also include performance 
data where practical. 

Submissions must be in the form of extended 
abstracts (1500-2500 words; 3-5 pages in length). 
Shorter abstracts might not give the program 
committee enough information to judge your 
work fairly and, in most cases, your submission 
will be rejected. Longer abstracts and full papers 
simply cannot be read by the committee in the 
time available. Feel free to append a full paper to 
an extended abstract; this is sometimes useful 
during evaluation. The extended abstract should 
represent your paper in short form. The committee 
wants to see that you have a real project, that you 
are familiar with the work in your area, and that 
you can clearly explain yourself. 

Please note that presentations are usually sched¬ 
uled to last 25 minutes. Your presentation should 
provide an overview of your paper and entice 
your audience to read it in the proceedings and 


hopefully follow up on your solution, or take 
your advice into consideration. 

Papers will be judged on technical merit, rele¬ 
vance to the theme, and suitability for presenta¬ 
tion. Papers are welcome from software (and 
hardware) vendors who wish to share their inno¬ 
vative solutions and techniques, but be fore¬ 
warned that product marketing will not be toler¬ 
ated. 

Persons interested in participating in panel dis¬ 
cussions should contact <woods@usenix.org>. 

Tutorial Program 

Tutorial Coordinator: Dan Klein 
<dvk@usenix.org> Tel; 412-421-2332 

Explore topics essential to successful use and 
development of UNIX and UNIX-like operating 
systems, X windows, networking and interopera¬ 
bility, advanced programming languages, and 
related areas of interest. The USENIX Associa¬ 
tion's well-respected tutorial program offers you 
introductory and advanced, intensive yet practi¬ 
cal tutorials. Courses are presented by skilled 
teachers who are hands-on experts in their topic 
areas. 

In an effort to continue to provide the best possi¬ 
ble tutorial slate, USENIX is soliciting proposals 
for new tutorials. If you are interested in present¬ 
ing a tutorial, contact the Tutorial Coordinator 
(see above). 

Invited Talks 

Interim Invited Talks and Panel Co-ordinator: 
Greg Woods <woods@usenix.org> 

As part of the technical sessions, a series of 
invited talks provides introductory and 
advanced information about a variety of interest¬ 
ing topics, such as using standard UNIX tools and 
employing specialized applications. We welcome 
suggestions for topics as well as request propos¬ 
als for particular talks. In your proposal, state the 
main focus, include a brief outline, and be sure to 
emphasize why your topic is of general interest to 
our commimity. 

BIrds-of-a-Feather Sessions 

BOF Scheduling: USENIX Conference Office 
<conference@usenix.org> 

Birds-of-a-Feather sessions (BoFs) bring together 
devotees of many varied disciplines for discus¬ 
sions, armoimcements, mingling, and strategy 
sharing during evenings at the symposium. 
Schedule a BoF in advance or on-site. 
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Work-in-Progress Reports 

WIPS Coordinator: Greg Woods 
<woods@usenix.org> 

These reports provide researchers with 10 min¬ 
utes to speak on current work and receive valu¬ 
able feedback. Present your interim results, 
novel approaches, or newly-completed work. 
Schedule your report in advance or on-site. 

For More Information 

Materials containing all details of the technical 
and tutorial program, conference registration, 
hotel and airline discoimt and reservation infor¬ 
mation will be mailed in January of 1993. 

For further information about the Symposium, 
contact the Program Chair: 


Program Chair 

Greg A. Woods 
#3 - 46 Three VaUeys Drive 
Don Mills, Ontario 
M3A3B5, CANADA 
<woods@usenix.org> 

+1 416 443-1734 
+1 416 595-5425 [FAX] 

Current Program Committee: 

Rob Kolstad, Berkeley Software Design 
<kolstad@bsdi.com> 

Evan Leibovitch, Soimd Software 
<evan@telly.on.ca> 

Peter Renzland, Ontario Government 
<peter@renzland.org> 

Dan Tomlinson, Compusoft 
<compus!dan@uunet.uu,net> 

Greg Woods, Elegant Communications 
<iuoods@usenix. org> 

Elizabeth Zwicky, SRI International 
<zwicky@erg.sricom> 


Mach Symposium 


Preliminary Announcement 
& Call for Papers 
Santa Fe, NM 
April 19-21,1993 

Extended Abstracts Due: December 4,1992 

Background 

The use and influence of Mach on the operating 
systems community continues to grow. From its 
beginnings as a small research project, Mach has 
spread to become the basis for commercial prod¬ 
ucts from a variety of vendors, and a key compo¬ 
nent of innovative research efforts in both 
academic and industrial environments. At the 
same time, research and development continue to 
evolve Mach itself. The community of researchers 
and developers working with Mach is proving to 
be a very productive source of innovative sys¬ 
tems. 

Activity in this field has been sufficiently wide¬ 
spread that the USENIX Association is pleased to 
once again sponsor a Mach symposium to bring 


together researchers, engineers, vendors and 
users of Mach systems. We will encourage discus¬ 
sion of all past and present Mach-related research, 
development, production, and applications activ¬ 
ities. 

Symposium Overview 

The symposium will be spread over three days. 
The first day will be devoted to tutorials on Mach 
3.0, and will include both introductory/overview 
and advanced programming tracks. These tutori¬ 
als should be of interest to both those desiring an 
introduction to Mach, and to programmers inter¬ 
ested in learning how to take better advantage of 
Mach features. The following two days will con¬ 
centrate on presentation of refereed papers on 
past and present Mach-related work. Long breaks 
between presentations will provide opportunities 
for informal discussion. Some time will be avail¬ 
able for descriptions of work in progress. 

Extended abstracts of 1500-2500 words (9000- 
15000 bytes or 3-5 pages) should be sent to David 
Black at the address below (those submitting 
hardcopy abstracts must send five copies). 
Shorter abstracts run a significant risk of rejection 
as there will be little on which the program com¬ 
mittee can base an opinion. In addition to the 
extended abstract, authors must also supply an 
outline of the full paper and an estimate of its 
length. 
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A good extended abstract will contain the follow¬ 
ing information in one form or another: 

Abstract 100-300 words (half a page) 

included verbatim in the final 
paper 

Introduction The problem; its importance; 
previous work 

Solution Issues, decisions, tradeoffs, 

rationale 

Implementation details 

Evaluation Performance results; effort 
required; lessons learned. 

Conclusion 

The extended abstract allows the program com¬ 
mittee to analyze the content of the proposed 
paper. An outline lists the headings, major points, 
and many minor points for each section of the 
actual paper. 

The outline should provide an idea of the form 
and style of your paper. This layout is not cast in 
concrete; just submit enough material to convince 
the committee that they want to accept the paper! 

Longer abstracts (up to and and including full 
papers) will be reviewed; the program committee 
appreciates any additional material that makes it 
easier to predict the content, organization, and 
style of the final paper. Authors should exercise 
appropriate restraint in determining the amoimt 
of material to submit. 

The submission package must include: 

•The extended abstract 
•Outline of rest of paper 
•Cover letter, detailing: 

Title of paper 
Authors 

Estimate of paper length 
Contact author (liaison to program com¬ 
mittee) 

E-mail address and daytime phone 
number for contact author 
Hours during which the daytime phone 
number can be used 
Surface mail address 
Optional FAX and home phone numbers 

If hardcopy is being subnutted, five copies of the 
submission. 

The submission should be sent electronically to 
dlb@osf.org, or by surface mail (five copies of 
abstract) to David Black at the address listed 


below. Submissions made by FAX will not be 
accepted. 

Electronic submissions must be in plain text that 
can be reviewed in the form submitted; the pro¬ 
gram committee does not have the time to rim 
formatting tools (e.g., TeX, LaTeX) or to figure out 
why a printer refuses to print some PostScript 
document. 

All submissions will be acknowledged. Authors 
of approved abstracts will be required to submit 
full-length papers (8-15 pages) approximately 
five weeks after notification of acceptance. For¬ 
matting guidelines will be provided. 

Areas of interest include, but certainly are not 
limited to: 

• Applications and support for program- 
nung languages 

• Mach 2.5 and related systems (e.g., OSF/1) 

• Mach 3.0 and servers 

• Mach-based operating system implementa¬ 
tion and emulation 

• Use of Mach subsystems in other operating 
systems 

• Multiprocessor and parallelization 
experience 

• Distributed systems, including multicom¬ 
puters, clusters, etc. 

• Real Time 

• Security 

• Performance 

• Productization experiences 

• Comparisons of Mach with other operat¬ 
ing systems (e.g.. Chorus, Sprite, Amoeba, 
V, and of course, UNIX) 

• Future work 

The program committee is especially interested in 
papers describing applications and/or system 
servers that take advantage of Mach features in 
addition to papers describing the evolution of 
Mach kernel technology. Submissions are 
strongly encouraged from efforts across the entire 
spectrum from research projects to product 
development efforts (including work that falls 
between these endpoints). 

Important dates; 

Extended abstracts: December 4,1992 

Notification to Authors: January 18,1993 

Camera-ready, full papers: February 26,1993 

For further information about the symposium, 
contact the program chair at the address on the 
following page. 
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Program Committee 


Program Chair 

David Black 
Research Institute 
Open Software Foundation 
1 Cambridge Center, 11th Floor 
Cambridge, MA 02142 
Voice: +1 (617) 621-7347 
FAX: +1(617) 621-8696 
E-Mail: dlb@osf.org 


David Black, Open Software Foundation 
David Golub, Carnegie Mellon University 
Alan Langerman, Orca Systems, Inc. 

Jay Lepreau, University of Utah 
Avadis Tevanian, Jr., NeXT, Inc. 


EurOpen Spring '93 Conference 


Call for Papers 
Seville, Spain 
May 3-7,1993 

The UUES (Spanish UNIX User Group) will host 
the 24th EurOpen Conference and Exhibition in 
Seville, Spain, on May 3-7,1993. 

The event is centered on a conference, exhibition 
and associated tutorials, dedicated to UNIX and 
Open systems. 

The three day conference with local commercial 
Exhibition will take place on May 5-7. It will be 
preceded by two days of Tutorials. 

A pre-conference registration pack containing 
detailed information will be available early in 
1993. 

The theme of the Seville Conference is: "Open Sys¬ 
tems from the desktop to the machine room: the 
new challenge." 

Many believe that UNIX can provide a single open 
environment for machines from desktop size to 
mainframes and super-computers. However, it is 
uncertain that UNIX will sustain its current mod¬ 
erate penetration in the desktop market, and some 
commercial DP and MIS departments have been 
slow to adopt UNIX. Remaining sufficiently open 
presents a new challenge to the UNIX community. 

One of the attractions of UNIX is reputedly the 
ability to easily migrate applications between var¬ 
ious hardware bases. This includes the possibility 
of migrating from large centralised systems across 
to distributed client-server environments, includ¬ 


ing desktop support. Once again, openness and 
portability are critical issues. 

Within the UNIX community itself, there is sig¬ 
nificant interest in the possibility of small micro¬ 
kernels providing a flexible replacement for 
monolithic UNIX environments. Such flexibility 
may be the key to providing growth from small 
systems to very large ones, particularly multi¬ 
computers. They may also be a basis towards 
openness for non-UNIX operating systems by 
providing a multi-faceted environment within a 
single machine. 

A consequence of openness in approach is that 
users can acquire and understand UNIX at lim¬ 
ited cost. In practice this not only results from 
using a desktop, rather than a mainframe 
machine, but also from the availability of public 
domain as well as proprietary software, and low 
cost UNIX implementations. Training and sup¬ 
port must likewise be open, in the sense that they 
must be sufficiently flexible to meet the highly 
varied requirement of end users. 

Important Dates 

Deadline for receipt of full papers, or extended 
abstracts, by the Secretariat: October 25,1992 

Notification to authors of the Programme Com¬ 
mittee's decision: November 29 ,1992 

Deadline for receipt of the final paper: 

January 29,1993 

Submission of Papers 

Paper submissions should identify the author(s) 
and the organisation(s) to which they belong. A 
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submission should include a draft of the complete 
paper (5 to 10 pages), or at least an extended 
abstract (at least 2 pages). Each will be examined 
on the basis of its originality, clarity, technical 
quality, and adherence to the general theme of the 
conference. 

The Programme Committee wishes to include 
both technical papers and syntheses of different 
approaches. The quality of the Conference 
depends to a large extent on the quality of the pre¬ 
sentations and papers: authors are thus strongly 
encouraged to supply a complete version of their 
text as soon as possible. 

Submissions should be sent direct to the EurOpen 
Secretariat (address below). 

Tutorials: 

The tutorials will provide attendees with infor¬ 
mation on specific topics. Their purpose will be to 
present the state of the art in important areas of 
open systems. The tutorials will be led by experts 
of national and international fame. Those inter¬ 
ested in offering a tutorial should contact the 
EurOpen Tutorial Executive as soon as possible. 

Useful Addresses 

Secretariat 

EurOpen Secretariat 
Owles Hall 
Buntingford 
UK-Herts SG9 9PL 
Telephone: +44 763 73039 
Facsimile: +44 763 73255 
Email: europen@EU.net 


Program Chair 

Dr. Chris Horn 
Iona Technologies 
Innovation Center 
Trinity College 
Dublin 2 Ireland 
Tel: + 353 1 679 0677 
Facsimile: + 353 1 679 8039 
Email: hom@iona.ie 

Tutorial Executive 

Neil Todd 
GID Ltd. 

1 Captains Close 
Upper Basildon 
Reading, Berks RG8 8SZ 
UK 

Telephone: + 44 491 671 964 
Facsimile: + 44 763 73255 
Email: neil@pio.gid.co.uk 
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Publications Order Form 


Subscription to Proceedings 


Please enter my one-year subscription"^ to the 1992 USENIX Conference, Workshop and Symposia 
Proceedings, which include: 

San Francisco Technical Conference - January 1992 

Symposium on Experiences with Distributed & Multiprocessor Systems (SEDMS) III - March 1992 
Workshop on Micro-Kernels and other Kernel Architectures - April 1992 
File Systems Workshop - May 1992 
San Antonio Technical Conference - June 1992 
C++Conference - August 1992 
UNIX Security III Symposium - September 1992 
Systems Administration (LISA) VI Conference - October 1992 


♦NOTE: 

Corporate. Educational and Supporting Members of 
USENIX automatically receive a subscription to all 
proceedings published during their term of 
membership, which may overlap with this offer. 


COST: USENIX members: $170.00 
Non-members: $214.00 
Outside U.S.A. and Canada? 
Add $30.00 for surface postage. 


Subscription Cost 
Calif. Sales Tax 
Overseas Postage 
TOTAL ENCLOSED 


^ If you are paying member price, please include member's name and/or membership number_ 


PAYMENT OPTIONS 


IZH Check enclosed payable to USENIX Association. Q Purchase order enclosed. 
I I Please charge my: Q Visa Q] MasterCard 

Account #_ _ _ 

Signature_ 


Exp. Date 


Outside the U.S.A.? Please make your payment in U.S. currency by one of the following: 

♦ Check - issued by a local branch of a U.S. Bank 

* Charge (Visa, MasterCard, or foreign equivalent) 

International postal money order 


4/92 




Name 

Address 

City __State/Country _ 

Please mail this order form to: USENIX Association 

2560 Ninth Street, Suite 215 
Berkeley, CA 94710 
510/528-8649 
FAX 510/548-5738 
office@usenix.org 

The proceedings are shipped the week following the event. 


Zip/Postal Code 


This offer is good tlirough 
DecL'mber.ll, 1992 
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Publications Order Form 


Conference & Workshop Proceedings 


Qty Proceedings 

Member 

Price 

Non-Member* 

Price 

Subtotal 

Overseas 

Postage 

Total 

WINTER/SUMMER CONFERENCES 







San Antonio 

Summer '92 

$23 

$30 

$ 

$14 

$ 

San Francisco 

Winter '92 

30 

39 

$ 

22 

$ 

Nashville 

Summer '91 

32 

38 

$ 

22 

$ 

Dallas 

Winter '91 

28 , 

34 

$ 

18 

$.. 

Anaheim 

Summer '90 

22 ' 

22 

$ 

15 

$ 

Washington, DC 

Winter '90 

25 

25 

$ 

15 

$ 

Baltimore 

Summer '89 

20 

20 

$ 

15 

$ 

San Diego 

Winter '89 

30 

30 

$ 

20 

$ 

San Francisco 

Summer '88 

29 

29 

$ 

20 

$ . 

Dallas 

Winter '88 

26 

26 

$ 

15 

$ 

Phoenix 

Summer '87 

35 

35 

S 

20 

$ 

Washington, DC 

Winter '87 

10 

10 

$ 

15 

$ 

Atlanta 

Summer '86 

37 

37 

$ 

20 

$ 

Denver 

Winter '86 

25 

25 

$ 

15 

$ 

Portland 

Summer '85 

45 

45 

$ 

25 

$ 

Dallas 

Winter '85 

15 

15 

$ 

10 

$ 

_Salt Lake City 

Summer '84 

29 

29 

$ 

20 

$ 

_Washington, DC 

Winter '84 

25 

25 

$ 

15 

$ 

Toronto 

Summer '83 

32 

32 

$ 

20 

$ 

San Diego 

Winter '83 

28 

28 

$ 

15 

$ 

LARGE INSTALLATION SYSTEMS ADMINISTRATION 






LISAV 

Sept. '91 

20 

23 

$ 

11 

$ 

LISA IV 

Oct. '90 

15 

1 

$ 

8 

$ 

LISA III 

Sept. '89 

13 

13 

$ 

9 

$ 

LISA II 

Nov. '88 

8 

8 

$ 

5 

$ 

_LISA I 

April '87 

4 

4 

$ 

5 

$ 

C++ 







C++ Conference 

Aug. '92 

30 

39 

$ 

20 

$ 

_ C++Conference 

Apr. '91 

22 

26 

$ 

11 

s 

C++ Conference 

Apr. '90 

28 

28 

$ 

18 

$ 

C++ Conference 

Oct. '88 

30 

30 

$ 

20 

$ 

_ C++Workshop 

Nov. '87 

30 

30 

$ 

20 

$ 

SECURITY 







UNIX Security II 

Aug. '90 

13 

16 

$ 

8 

$ 

UNIX Security 

Aug. '88 

7 

7 

$ 

5 

$ 

MACH 







_ Mach Symposium 

Nov. '91 

24 

28 

s 

14 

$ 

_Mach Workshop 

Oct. '90 

17 

20 

$ 

9 

$ 


Continued • see reverse 
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Qty Proceedings 

Member 

Price 

Non-Memher* 

Price 

Subtotal 

Overseas 

Postage 

Total 

DISTRIBUTED & MULTIPROCESSOR SYSTEMS (SEDMS) 






SEDMS III 

Mar. '92 

30 

36 

$ 

20 

$ 

SEDMS II 

Mar. '91 

30 

36 

$ 

20 

$ 

SEDMS 

Oct. '89 

30 

1 30 

$ 

20 

$ 

GRAPHICS 



j 




Graphics Workshop V 

Nov. ’89 

18 

18 

S 

10 

$. 

Graphics IV 

Oct. '87 

10 

10 

$ 

10 

$ 

Graphics III 

Nov. '86 

10 

1 

$ 

5 

$ 

Graphics II 

Dec. '85 

7 

7 

$ 

5 

$ 

OTHER WORKSHOPS 







File Svstems 

Mav '92 

15 

20 

$ 

9 

$ 

Micro-Kernel & Other Kernel Arch. April '92 

30 

39 

$ 

20 

$ 

UNIX Transaction Processing 

May '89 

12 

12 

$ 

8 

$ 

Software Management 

Apr, '89 

20 

20 

$ 

15 

$ 

UNIX & Supercomputers 

Sept. '88 

20 

20 

$ 

10 

s 


Discounts are available for hulk orders. Please inquire. Total price of Proceedings _ 

Calif, residents add sales tax _ 

Total overseas postage _ 

Total enclosed _ 

**If you are paying member price, please include member's name and/or 
membership number^__ 


PAYMENT OPTIONS* 

_Check enclosed - payable to USENIX Association 

_Charge my: _ VISA i^E]_ MC Account #_ _ Exp.Date 

_ Purchase order enclosed Signature-- 

* Outside the USA? Please make your payment in US currency by one of the following: 

- Check - issued by a local branch of a US Bank 

- Charge (VISA, MasterCard, or foreign equivalent) 

- International postal money order 

Shipping Information Ship to: 

Please allow 2-3 weeks for delivery. Overseas orders 
are shipped via air printed matter. 

Please mail or fax this order form with payment to: 

USENIX Association 
2560 Ninth Street, Suite 215 
Berkeley, CA 94710 
FAX 510/548-5738 

• If you are not a member and wish to receive our membership information packet, please check this box. dl 
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Local User Groups 


The Association will support local user groups by 
doing a mailing to assist in the formation of a new 
group and publishing information on local 
groups in ;login:. At least one member of the 
group must be a current member of the Associa¬ 
tion. Send additions and corrections to: 
login@usenix.org. 


CA - Fresno: 

The Central California UNIX Users Group con¬ 
sists of a uucp-based electronic mailing list to 
which members may post questions or informa¬ 
tion. For connection irtformation: 

Educational and governmental institutions: 
Brent Auernheimer (209) 278-2573 
brent@CSUFresno.edu or csufresibrent 

Commerical institutions or individuals: 

Gordon Crumal (209) 251-2648 
csufres Igor don 

CA - Orange County: 

Meets the 2nd Monday of each month 

UNIX Users Association of Southern California 
Paul Muldoon (714) 556-1220 ext. 137 
New Horizons Computer Learning Center 
1231 E. Dyer Rd., Suite 140 
Santa Ana, C A 92705 

CO - Boulder: 

Meets monthly at different sites. For meeting 
schedule, send email to fruug-info@fruug.org. 

Front Range UNIX Users Group 
Software Design & Analysis, Inc. 

1113 Spruce St,, Ste. 500 
Boulder, CO 80302 
Steve Gaede (303) 444-9100 
gaede@fruug.org 

FL - Coral Springs 

S. Shaw McQuinn (305) 344-8686 
8557 W. Sample Road 
Coral Springs, FL 33065 


FL - Western: 

Meets the 1st Thursday of each month. 

Florida West Coast UNIX Users Group 
Richard Martino (813) 536-1776 
Tony Becker (813) 799-1836 
mcrsysitony 

Ed Gallizzi, Ph.D. (813) 864-8272 
e.galizzi@compmail. com 
Jay Ts (813) 979-9169 
uunetlpdnitscsimetranijan 
Dave Lewis (407) 242-4372 
dhl@ccd.harris.com 

FL - Orlando: 

Meets the 3rd Thursday of each month. 

Central Florida UNIX Users Group 

Mike Geldner (407) 862-0949 

codas Isunfla! mike 

Ben Goldfarb (407) 275-2790 

goldfarb@hcx9.ucf.edu 

Mikel Manitius (407) 869-2462 

(codas,attmaiUlmikel 

FL - Melbourne 

Meets the 3rd Monday of every month. 

Space Coast UNIX User's Group 
Steve Lindsey (407) 242-4766 
lindsey@vnet. ibm. com 

KS or MO - Kansas: 

Meets on 2nd Monday of each month. 

Kansas City UNIX Users Group (KUUG) 

813B St. 

Blue Springs, MO 64015 
(816) 235 5212 
mlg@cstp.umkc.edu 

GA - Atlanta: 

Meets on the 1st Monday of each month in White 
Hall, Emory University. 

Atlanta UNIX Users Group 
P.O. Box 12241 
Atlanta, GA 30355-2241 
Mark Landry (404) 365-8108 

Ml - Detroit/Ann Arbor: 

Meets on the 2nd Thursday of each month in Ann 
Arbor. 

Southeastern Michigan Sun Local Users Group 
and Nameless UNIX Users Group 
Steve Simmons office: (313) 769-4086 
home: (313) 426-8981 
scs@lokkur. dexter, mi.us 
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Ml ■ Detroit/Ann Arbor (cont.) 

K. Richard McGill 
rich@sendai.ann-arbor.mi.us 
Bill Bulley 
web@applga.uucp 

MN- MInneapolls/St Paul: 

Meets the 1st Wednesday of each month. 

UNIX Users of Minnesota 
17130 Jordan Court 
Lakeville, MN 55044 
Robert A. Monio (612) 220-2427 
pnessutt@dmshq.mn.org 

MO - St. Louis; 

St. Louis UNIX Users Group 
P.O, Box 2182 
St. Louis, MO 63158 
Terry Linhardt (314) 772-m2 
uunetljgaltstl! terry 

NE-Omaha: 

Meets monthly. 

/usr/group/nebraska 

P.O. Box 31012 

Omaha, NE 68132 

Phillip Allendorfer (402) 423-1400 

New England - Northern: 

Meets monthly at different sites. 

Peter Schmitt 603) 646-2085 
Kiewit Computation Center 
Dartmouth College 
Hanover, HN 03755 
Peter.Schmitt@dartvaxldartmouth.edu 

NJ ■ Princeton: 

Meets monthly. 

Princeton UNIX Users Group 

Mercer County Community College 

1200 Old Trenton Road 

Trenton, NJ 08690 

Peter J. Holsberg (609) 586-4800 

mccdpjh 

NY-New York City: 

Meets every other month in Manhatten. 

Urugroup of New York City 
G.P.O. Box 1931 
New York, NY 10116 

Peter Gutmann (212) 618-0973 peterg@murphy.com 


OK-Tulsa: 

Meets 2nd Wednesday of each month. 

Tulsa UNIX Users Group, $USR 
Stan Mason (918) 560-5329 
tulsixlsmason@drd.com 
Mark Lawrence (918) 743-3013 
mark@drd.com 

TX-Austin: 

Meets 3rd Thursday of each month. 

Capital Area Central Texas UNIX Society 

P.O. Box 9786 

Austin, TX 78766-9786 

officers@cactus.org 

Tom Painter (512) 835-5457 

president@cactus.org 

TX-Dallas/Fort Worth: 

Dallas/Fort Worth UNIX Users Group 
660 Preston Forest, Suite 177 
DaUas, TX 75230 
Kevin Coyle (214) 991-5512 
kevincd@shared. com 

TX - Houston: 

Meets 3rd Tuesday of each month. 

Houston UNIX Users Group 
(Hounix) answering machine (713) 684-6590 
Bob Marcum, President (713) 270-8124 
Chuck Bentley, Vice-president 
(713) 789-8928 chuckb@hounix.uucp 

WA - Seattle; 

Meets monthly. 

Seattle UNIX Group Membership Info. 

Bill Campbell (206) 947-5591 
6641 East Mercer 
Mercer Island, WA 98040-0820 
bill@celestial.com 

Washington, D.C.; 

Meets 1st Tuesday of each month. 

Washington Area UNIX Users Group 

9811 Mallard Drive 

Laurel, MD 20708 

Alan Fedder (301) 953-3626 

CANADA - Toronto: 

143 Baronwood Court 
Brampton, Ont. Canada L6V 3H8 
Evan Leibovitch (416) 452-0504 
evan@telly.on.ca 
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Calendar of Events 


1992 

Sep 8-11 AUUG, Melbourne, Australia 
14-17 UNIX Security III, Baltimore, MD 
22-24 UNIX Expo, New York, NY 
Oct 6 ISO/IEC ITCl SC22 WG15, Denmark 

18- 22 OOPSLA, Vancouver, Canada 

19- 23 LISA VI, Long Beach, CA 
19-23 IEEE 1003, Utrecht, Netherlands 

26-30 Interop, San Francisco, CA 
27 - 30 ISO/IEC JTCl SC22 WG15 
Reading, UK 

Nov 25-27 EurOpen/UniForum 
Utrecht, Netherlands 
Dec 7 Sun User Group, San Jose, CA 

UKUUG/UKnet, Manchester, UK 

1993 

Jan 11-15 IEEE 1003, New Orleans, LA 
25-29 * USENIX, San Diego, CA 
Feb 22-24 Sun Open Sys. Expo, Chicago, IL 

Mar 15-18 UniForum, San Francisco, CA 
31 - UNIX Applications Development 
Apr 1 Toronto, Canada 

19-21 Mach, Santa Fe, NM 
19-23 IEEE 1003 

May 3-7 EurOpen, Seville, Spain 

Jim 21-25 * USENIX, Cincinnati, OH 

Jul 12-16 IEEE 1003 
Autumn EurOpen/UniForum 
Utrecht, Netherlands 

* LISA VII 

* SEDMS 
Micro-Kernel 

Oct 18-22 IEEE 1003 

25-29 Interop, San Francisco, CA 

1994 

Jan 17-21 * USENIX, San Francisco, CA 
Feb 14-17 UniForum, Dallas, TX 
Mar 23-25 UniForum, San Francisco, CA 
Apr 18-22 EurOpen 


Jun 6-10 * USENIX, Boston, MA 
Sep 12-16 Interop, San Francisco, CA 
Autumn EurOpen/UniForum 
Utrecht, Netherlands 

1995 

Jan 16-20 * USENIX, New Orleans, LA 
Feb 21-23 UniForum, Dallas, TX 
May 1- 5 EurOpen 
Jim 19-22 * USENIX, San Francisco, CA 


1996 

Jan 22-26 * USENIX, San Diego, CA 
Mar 11-14 UniForum, San Francisco, CA 


This is a combiaed calendar of planned conferences, 
workshops, and standards meetings related to the UNIX 
operating system. If you have a UNIX-related event that 
ou wish to publicize, please contact Jogtn^itseniXrOrg. 
lease provide your inh>rmation in the same format as 
above^ This calendar has been compiled with the assis¬ 
tance of Alain WLlhams of EurOpen. 

* = events sponsored by the USENIX Association. 


ACE: Advanced ComputingEnvirorunents 
ACM: Association for Computing Madiinery 
AFUU: Association Francaise des UHlisateurs d'UNIX 

AUUG: Australian UNIX Users Group 

DEGUS: Digital Emiipment ComputerUsers Society 

ECUG: European C++ User Group 

EurOpen: European Forum for Open Systems 

GUUG: German UNIX Systems User Group 

IEEE: Institute of Electrical and Electronics Engineers 

IETF: Internet Engineering Task Force 

Interex: Internat'l Assoc.-Hewlett-Packard Comp.Users 

JUS: Japan UNIX Society 

LISA: USENIX Systems Administration Conference 
NIST: National Institute of Standards ^Technology 
SEDMS: Symposium on Experiences with Distributed 
and Multiprocessor Systems 

Sinix: Singapore LJNDC Association 

UKUUG: United Kingdom UNIX Systems Users Group 
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USENIX Association 
2560 Ninth Street, Suite 215 
Berkeley, CA 94710 
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At Berkeley, California 
and Additional Offices 


What’s Inside? 


Special Technical Groups 
New Section: SAGE 
Micro-Kernel Workshop Report 

Standards Activity Update 
The Bookworm 




